- Add comprehensive documentation for new --exit-code and --no-exit-code flags
- Include CI/CD integration examples showing script usage
- Document exit code behavior (0=success, 1=validation failure, 2=usage error)
- Update validation examples to show both success and failure cases
- Add GitLab CI validation examples
- Update feature list to highlight CI/CD integration capabilities
- Add --exit-code flag (default: true) to set exit code 1 on validation failure
- Add --no-exit-code flag to disable exit code setting for script flexibility
- Modify validation functions to return boolean failure status
- Track validation failures across multiple files in directory validation
- Ensure proper exit codes for both GitHub workflows and GitLab CI pipelines
- Maintains backwards compatibility while enabling CI/CD integration
Closes #[issue-number] if applicable
- Add support for job-level if conditions with basic expression evaluation
- Support both string and array formats for job needs field (needs: job vs needs: [job])
- Add missing job fields: if_condition, outputs, permissions to Job struct
- Implement job condition evaluation in executor with pattern matching for:
- Simple boolean conditions (true/false)
- GitHub event conditions (github.event.pull_request.draft == false)
- Job output conditions (needs.jobname.outputs.outputname == 'value')
- Jobs with false conditions are now properly skipped with appropriate logging
- Fixes parsing issues with workflows that use changes jobs and conditional execution
Resolves compatibility with workflows like iceoryx2 that use path filtering patterns.
- Add documentation for --preserve-containers-on-failure flag
- Include usage examples for both CLI and TUI modes
- Explain when and how containers are preserved for debugging
- Add example of the helpful debugging message users will see
- Update CLI examples section to showcase the new feature
- Add CLI flag to preserve Docker containers when tasks fail
- Create ExecutionConfig structure to pass configuration through system
- Modify DockerRuntime to conditionally skip container cleanup on failure
- Add support for both CLI run and TUI modes
- Log helpful debugging messages with container ID and inspection commands
- Preserve containers only when exit_code != 0 and flag is enabled
- Untrack preserved containers from automatic cleanup system
Fixes issue where failed containers were always deleted, preventing users
from inspecting the actual state when debugging workflow failures.
Replace remaining io::Error::new(io::ErrorKind::Other, msg) with
io::Error::other(msg) in workflow validation error handling.
Also apply cargo fmt to fix formatting.
- Replace io::Error::new(io::ErrorKind::Other, e) with io::Error::other(e) in workflow handler
- Add explicit lifetime annotations to UI component render methods to fix mismatched-lifetime-syntaxes warnings
- These changes ensure CI passes with -D warnings flag
All changes are backwards compatible and maintain existing functionality.
Replace io::Error::new(io::ErrorKind::Other, e) with the newer
io::Error::other(e) method as recommended by clippy.
This fixes CI failures when running with -D warnings that treat
clippy::io_other_error as an error.
GitHub Actions requires step IDs to be unique within each job scope, but wrkflw
was not validating this constraint. This caused workflows with duplicate step
IDs to pass validation with exit code 0, while GitHub would reject them with
"The identifier 'X' may not be used more than once within the same scope".
- Add HashSet tracking of step IDs in validate_steps()
- Check for duplicate IDs and report validation errors
- Use GitHub's exact error message format for consistency
- Step IDs can still be duplicated across different jobs (which is valid)
Fixes validation gap that allowed invalid workflows to pass undetected.
This commit adds full support for GitLab CI/CD pipelines:
- Add GitLab CI pipeline models with complete spec support (jobs, stages, artifacts, cache, etc.)
- Implement GitLab CI/CD pipeline parsing and validation
- Add schema validation against GitLab CI JSON schema
- Support automatic pipeline type detection based on filename and content
- Add GitLab-specific CLI commands and flags
- Implement pipeline conversion for executor compatibility
- Add validation for common GitLab CI configuration issues
- Update CLI help text to reflect GitLab CI/CD support
- Support listing both GitHub and GitLab pipeline files
This expands wrkflw to be a multi-CI tool that can validate and execute both GitHub
Actions workflows and GitLab CI/CD pipelines locally.
- Split monolithic lib.rs (3700+ lines) into logical modules
- Create directory structure for app, models, components, handlers, utils, and views
- Implement reusable UI components (Button, Checkbox, ProgressBar)
- Separate view rendering code by screen function
- Fix all compiler warnings and linter issues
- Maintain existing functionality while improving code organization
- Follow Rust best practices for module hierarchy and separation of concerns
This change makes the UI codebase easier to navigate, maintain and extend
without changing any of the existing behavior.
Consolidated the main binary (main.rs) and library root (lib.rs)
from the top-level src/ directory into the dedicated crates/wrkflw
crate. This aligns the project structure with standard Rust
workspace conventions.
- Moved src/main.rs to crates/wrkflw/src/main.rs
- Moved src/lib.rs to crates/wrkflw/src/lib.rs
- Updated use statements in crates/wrkflw/src/main.rs to directly reference other workspace crates (e.g., `executor`, `parser`).
- Updated crates/wrkflw/src/lib.rs to re-export workspace crates.
- Configured crates/wrkflw/Cargo.toml for both `[lib]` and `[[bin]]` targets.
- Removed the top-level src/ directory.
- Extracted functionality from the `src/` directory into individual crates within the `crates/` directory. This improves modularity, organization, and separation of concerns.
- Migrated modules include: models, evaluator, ui, gitlab, utils, logging, github, matrix, executor, runtime, parser, and validators.
- Removed the original source files and directories from `src/` after successful migration.
- This change sets the stage for better code management and potentially independent development/versioning of workspace members.
Previously, `run` steps in Docker jobs were failing due to several issues:
- They were hardcoded to use `ubuntu:latest`, which often lacked necessary tools like `cargo`.
- Even when the image was correct, the host workspace directory was not properly mapped into the container, preventing access to source files.
This commit addresses these issues by:
- Using the correct runner image specified by the job's `runs_on` field for `run` steps, instead of always defaulting to `ubuntu:latest`.
- Updating the `get_runner_image` function to map `macos-latest` runners to `rust:latest` to ensure the Rust toolchain is available for relevant workflows.
- Correctly mapping the host working directory to `/github/workspace` within the container for `run` steps.
- Setting the container's working directory to `/github/workspace` when executing `run` steps.
This allows commands like `cargo build` and `cargo test` within `run` steps to find both the necessary tools and the project source code inside the container.
Enhance the workflow validator to correctly handle GitHub Actions reusable workflows:
- Skip validation of 'runs-on' field for jobs with a 'uses' field
- Skip validation of the 'steps' field for reusable workflow jobs
- Add specific format validation for reusable workflow references
- Make workflow name optional for files that only contain reusable workflow jobs
- Add comprehensive test workflow files for various reusable workflow scenarios
This fixes validation errors when using GitHub's workflow_call feature that
allows reusing workflows from other repositories or local files.
