wrkflw

mirror of https://github.com/bahdotsh/wrkflw.git synced 2026-08-29 10:09:25 +02:00

Files

bahdotsh 9d858fdd84 fix(validators): reject non-mapping env values in validate

It turns out that `wrkflw validate` was happily accepting
`env: VAR=value` — a bare string — when GitHub Actions *only*
allows mappings for env. The reason is that the validate path
(evaluate_workflow_file) runs its own structural validators
but never actually checks the type of env fields. The JSON
schema gets it right, but it's only wired up in the parser
path, not the validator.

Add a validate_env() helper that checks env is either a YAML
mapping or an expression string (${{ }}), and wire it into
all three levels: top-level, job-level, and step-level. Tests
included for each.

Closes #89

2026-04-06 21:39:46 +05:30

src

fix(validators): reject non-mapping env values in validate

2026-04-06 21:39:46 +05:30

Cargo.toml

version fix

2025-09-05 08:22:15 +05:30

README.md

docs: clean up READMEs, remove dead files and bloat (#84 )

2026-04-02 23:58:51 +05:30

README.md

wrkflw-evaluator

Small, focused helper for statically evaluating GitHub Actions workflow files.

Purpose: Fast structural checks (e.g., name, on, jobs) and composite action input cross-checking before deeper validation/execution
Used by: wrkflw CLI and TUI during validation flows

Example

use std::path::Path;

let result = wrkflw_evaluator::evaluate_workflow_file(
    Path::new(".github/workflows/ci.yml"),
    /* verbose */ true,
).expect("evaluation failed");

if result.is_valid {
    println!("Workflow looks structurally sound");
} else {
    for issue in result.issues {
        println!("- {}", issue);
    }
}

Notes

This crate focuses on structural checks; deeper rules live in wrkflw-validators.
Most consumers should prefer the top-level wrkflw CLI for end-to-end UX.