🦊 GitLab CI: Automated Testing of Job Rules
Initial thoughts 1. The problem: CI rules complexity 2. The solution: automated job list validation gitlab-ci-local: the cornerstone How it works 3. Setting up the test infrastructure Directory str...
Source: DEV Community
Initial thoughts 1. The problem: CI rules complexity 2. The solution: automated job list validation gitlab-ci-local: the cornerstone How it works 3. Setting up the test infrastructure Directory structure Test case definition Reference CSV files 4. The validation script 5. The CI job 6. Workflow: adding or modifying jobs 7. Testing with rules:changes The problem with rules:changes and gitlab-ci-local The force-build label workaround Per-module test cases 8. Documentation that writes itself Wrapping up Further reading Initial thoughts As a CICD engineer, you've likely experienced this frustrating scenario: you modify a job's rules: to optimize pipeline execution, only to discover later that some jobs no longer trigger in specific situations. Or worse, jobs that should be mutually exclusive now run together, wasting resources and causing confusion. GitLab CI's rules: syntax is powerful but complex. With workflow:rules, job-level rules:, extends:, !reference, and changes: all interacting,
