Skip to content

Spec: phpboyscout/cicd v0.4 — gate components in MR pipelines

  • Repository: gitlab.com/phpboyscout/cicd
  • Released as: v0.4.0 (minor — a behaviour change across all four gate components: they now also run in merge-request pipelines).
  • Driver: phpboyscout/infra's Phase E MR — the gate checks ran on a separate push pipeline, not the MR pipeline, so they were not linked to the MR. The MR pipeline carried only tofu-plan.

Summary

The four gate components — tofu-lint, tofu-security, tofu-validate, zensical-pages — ship their jobs with no rules:. A GitLab job with no rules / only / except runs on branch and tag pipelines only — never on merge-request pipelines. So in a consumer that uses MR pipelines, the gate jobs land on the branch (push) pipeline while tofu-plan (which v0.3.0 gave an explicit merge_request_event rule) lands on the MR pipeline — two pipelines, the gates detached from the MR.

v0.4 gives every gate job an explicit rules: so it runs in all pipeline types, merge-request pipelines included.

Decisions

D1 — Every gate job gets rules: [{ when: on_success }]

rules:
  - when: on_success

An unconditional rule. The point is not to gate when the job runs — fmt / lint / scan / validate / docs are cheap and safe anywhere — but that having a rules: block at all is what lets a job run in a merge-request pipeline. A rule-less job is implicitly only: [branches, tags].

Applied to: tofu-fmt, tflint, terraform-docs-drift (tofu-lint); trivy-config, checkov, gitleaks (tofu-security); tofu-validate (tofu-validate); zensical-build (zensical-pages).

Non-breaking. A rule-less job ran on branch + tag pipelines; { when: on_success } runs on branch + tag + merge-request + parent-pipeline-child pipelines. Purely additive — existing consumers gain MR-pipeline coverage and lose nothing.

D2 — zensical-pages's pages job is unchanged

pages is a deploy, not a gate — it already carries rules: [{ if: $CI_COMMIT_BRANCH == deploy_branch }] and keeps it; a Pages deploy must not run from a merge-request pipeline. Only zensical-build (the gate half) gets the D1 rule.

D3 — Self-test: no change needed

The unconditional D1 rule matches in every context, including the parent_pipeline-source child pipelines the cicd self-test uses. Unlike the v0.3 component rules (keyed on $CI_PIPELINE_SOURCE / $CI_COMMIT_BRANCH, which the parent/child harness masks — D6 of that spec), the gate-component self-tests need no rule override. The tests/<component>/.gitlab-ci.yml files are unchanged.

D4 — Versioning

A behaviour change across all four gate components → v0.4.0. Non-breaking (D1), but a minor bump is correct for a cross-component behaviour change. Pre-1.0 caveat from v0.1 still applies.

Consumer note

v0.4 makes gate jobs run in both the merge-request pipeline and the branch (push) pipeline of an MR's source branch. A consumer that wants exactly one pipeline per feature branch adds a workflow: block to its .gitlab-ci.yml (merge-request pipelines + branch pipelines for the default branch + tag pipelines) — a consumer choice, not the component's. phpboyscout/infra adds such a block alongside adopting v0.4.

Component delta summary

tofu-lint.yml, tofu-security.yml, tofu-validate.yml, zensical-pages.yml — each gate job gains rules: [{ when: on_success }]; zensical-pages's pages deploy job is untouched.

Implementation plan

  1. Spec lands — this file, status approved.
  2. Add rules: to the gate jobs in the four component templates.
  3. CHANGELOG [0.4.0].
  4. Merge develop → main, tag v0.4.0.
  5. phpboyscout/infra bumps the component refs to @v0.4.0 and adds the workflow: block.