mirror of
https://github.com/bahdotsh/wrkflw.git
synced 2026-05-18 13:16:04 +02:00
452044f9d2
* feat(cli): add --job flag to run a specific job and --jobs to list them Until now, wrkflw only operated at the workflow level. You could run an entire workflow or list workflow files, but if you wanted to debug a single failing job you had to sit through every other job first. This is not great. Add `--job <name>` to `wrkflw run` so you can execute exactly one job in isolation, skipping dependency resolution entirely. Add `--jobs` to `wrkflw list` so you can actually *see* what jobs are available before running them. Both work for GitHub workflows and GitLab pipelines. The filtering happens after dependency resolution — we just replace the execution plan with a single-job batch. If the job name doesn't exist, we tell you what's available instead of silently doing nothing. The TUI still runs full workflows; job selection there is a separate concern. Closes #68 * fix(executor): include transitive deps when running a single job The --job flag was replacing the entire execution plan with just the target job, silently dropping all its dependencies. So if you ran --job deploy and deploy needs build which needs setup, you'd get deploy running alone with none of its prerequisites. Confusion ensues. Extract the duplicated inline filtering (copy-pasted verbatim across both the GitHub and GitLab execution paths) into a shared filter_plan_to_job() helper in dependency.rs. The new logic walks the needs graph via BFS to collect transitive deps, then prunes the existing topologically-sorted plan to only include relevant jobs while preserving batch ordering. Add 9 unit tests covering the dependency collection and plan filtering — linear chains, diamond graphs, partial subgraph isolation, error paths, and empty batch removal. * fix(executor): use stage-aware filtering for GitLab --job flag It turns out that filter_plan_to_job walks `needs` edges to find transitive dependencies, which works fine for GitHub workflows. But GitLab pipelines use *stage ordering* for implicit dependencies, and convert_to_workflow_format sets `needs: None` on every converted job. So running `--job deploy` on a GitLab pipeline would silently drop all build and test jobs. Not great. Add filter_plan_to_job_by_stage that understands the GitLab model: keep all jobs in earlier stage batches (they're implicit deps) and filter only the target's own batch down to just the target job. The GitHub workflow path continues using the needs-based filter. While at it, extract the job-not-found error into a shared helper and add proper test coverage: 6 unit tests for the stage-aware filter plus 3 integration tests exercising the full execute_workflow path with target_job set.
Testing Strategy
This directory contains all tests and test-related files for the wrkflw project. We follow the Rust testing best practices by organizing tests as follows:
Test Organization
- Unit Tests: Located alongside the source files in
src/using#[cfg(test)]modules - Integration Tests: Located directly in this
tests/directorymatrix_test.rs- Tests for matrix expansion functionalityreusable_workflow_test.rs- Tests for reusable workflow validation
- End-to-End Tests: Also located in this
tests/directorycleanup_test.rs- Tests for cleanup functionality with Docker resources
Test Directory Structure
fixtures/: Test data and configuration filesgitlab-ci/- GitLab CI configuration files for testing
workflows/: GitHub Actions workflow files for testing- Various YAML files for testing workflow validation and execution
scripts/: Test automation scriptstest-podman-basic.sh- Basic Podman integration test scripttest-preserve-containers.sh- Container preservation testing script
TESTING_PODMAN.md: Comprehensive Podman testing documentation
Running Tests
To run all tests:
cargo test
To run only unit tests:
cargo test --lib
To run only integration tests:
cargo test --test matrix_test --test reusable_workflow_test
To run only end-to-end tests:
cargo test --test cleanup_test
To run a specific test:
cargo test test_name
Writing Tests
Please follow these guidelines when writing tests:
- Use meaningful test names that describe what is being tested
- Group related tests together in modules
- Use helper functions to reduce duplication
- Test both success and failure cases
- Use
#[should_panic]for tests that expect a panic - Avoid test interdependencies