Files
wrkflw/tests
bahdotsh 06d4ecd2c2 fix(docker): persist setup action images across job steps
Reported in #60. When a workflow uses actions like setup-node or
setup-php, the Docker image resolved for that action (e.g.
node:20-slim, composer:latest) was only used for the action step
itself. Every subsequent `run:` step would blissfully fall back to
ubuntu:latest, which of course has neither node nor composer.

Confusion ensues.

It turns out that `execute_job()` computes `runner_image_value`
exactly *once* via `get_effective_runner_image()` and never updates
it. The action step gets its own image from `prepare_action()`, but
that image is completely ignored for subsequent `run:` steps. So
your setup-node configures... nothing, as far as run steps care.

Fix this by pre-scanning all job steps for known setup actions
before the step loop begins. Single setup action? Use its image.
Multiple setup actions (e.g. Laravel's PHP + Node.js combo)? Build
a combined Dockerfile that installs all required runtimes on the
ubuntu base. No setup actions? Nothing changes — fully backward
compatible.

While at it, skip the pointless pull attempt for locally-built
wrkflw-* images (they only exist locally, the 404 from Docker Hub
was just noise), and bump the build_image timeout from 2 minutes
to 10 — because installing PHP from a PPA inside a Docker build
is not a speed demon.

Closes #60
2026-04-02 10:57:28 +05:30
..

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/ directory
    • matrix_test.rs - Tests for matrix expansion functionality
    • reusable_workflow_test.rs - Tests for reusable workflow validation
  • End-to-End Tests: Also located in this tests/ directory
    • cleanup_test.rs - Tests for cleanup functionality with Docker resources

Test Directory Structure

  • fixtures/: Test data and configuration files
    • gitlab-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 scripts
    • test-podman-basic.sh - Basic Podman integration test script
    • test-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:

  1. Use meaningful test names that describe what is being tested
  2. Group related tests together in modules
  3. Use helper functions to reduce duplication
  4. Test both success and failure cases
  5. Use #[should_panic] for tests that expect a panic
  6. Avoid test interdependencies