contribution-pipeline

Contribution Pipeline (worker skill)

The authoritative final gate. Local verification (contribution-verify) is the fast inner loop; the real GitLab MR pipeline is the truth. A contribution is not done until the real drupalci pipeline is green.

Backs /drupal-ai-contrib:pipeline. Load the knowledge layer via dev-guides-navigator: drupal/contributing/drupalci-pipeline-gitlab-templates, drupal/contributing/reproducing-drupalci-failures-locally.

Procedure

1. Resolve the MR and project

Identify the GitLab project and merge-request for the current issue fork (from submit state, or ask). Before any API call, validate against an explicit pattern — the MR number must match ^[0-9]+$, the project path ^[A-Za-z0-9_./-]+$ — and reject anything that does not match rather than calling the API with it.

2. Fetch the pipeline — glab via the drupal-gitlab skill

Fetch the MR's latest pipeline and its jobs with glab, delegated to the drupal-gitlab skill (it owns the git.drupalcode.org auth + host rules; see its references/ci-cd.md). This is the produced artifact — the actual pipeline result, not a prediction:

glab ci status                                    # pipeline status for the MR's branch
glab ci view                                      # per-job overview
glab ci trace <job-name>                          # stream a job's full log (debug failures)

Always pass --repo "git.drupalcode.org/project/<repo>" (or run inside the configured git dir) — never rely on the default host. Credentials are the contributor's own (a read-only token suffices for status); never store or transmit them.

Two hard limits on git.drupalcode.org:

• Pipelines fire on push events only — API/CLI triggers (glab ci run, POST /pipeline) are blocked. To re-run CI, push a commit (an --allow-empty commit works); never claim a re-trigger you cannot perform.
• Never WebFetch a GitLab job/MR URL — the pages are JavaScript-rendered and return no log. Read job logs with glab ci trace <job> (or glab api … /jobs/<id>/trace).

3. Read the pipeline honestly

A pipeline reported "passed" can still hide problems. Inspect every job:

• allow_failure jobs — a red allow_failure job does not fail the pipeline but is still a real failure. Surface it.
• Manual / opt-in jobs — gitlab_templates v1.15.0+ moved opt-in variant jobs (OPT_IN_TEST_PREVIOUS_MAJOR, _PREVIOUS_MINOR, _NEXT_MINOR, _MAX_PHP) to manual trigger. An un-run manual job is not coverage. Report it explicitly as not run — never imply a green pipeline means those variants passed.

4. Gate

The contribution is done only when: every blocking job is green, every allow_failure job's real status is surfaced, and every relevant manual variant is either triggered-and-green or explicitly recorded as a deliberate non-goal.

If a job failed, diagnose it against the reproduction dev-guide and route the contributor back to development → verify. Do not mark the work complete on local green alone.

5. Report

Summarize per job: name, status, blocking vs. allow_failure vs. manual, and the link to the job log. State plainly: is the contribution done, or what remains. The verdict is the pipeline's — never assert "should pass".

Examples

Example 1: a green pipeline hiding a red allow_failure job

Trigger: /drupal-ai-contrib:pipeline Actions:

1. Fetch the MR pipeline — overall status "passed".
2. Inspect every job — phpstan is red but allow_failure: true. Result: Reported: pipeline green, but phpstan failed (non-blocking) — surfaced, not hidden.

Example 2: un-run manual variant

Trigger: /drupal-ai-contrib:pipeline Actions:

1. All blocking jobs green; the PREVIOUS_MAJOR variant is a manual job, never triggered. Result: Reported as UNRUN — not implied coverage; the contributor decides whether to trigger it.

Troubleshooting

Situation	Handling
No MR found for the branch	Report it; point at /drupal-ai-contrib:submit to create the MR first.
glab unauthenticated / API unreachable	Report the failure (glab auth login --hostname git.drupalcode.org); never substitute a local-green result for the real pipeline.
Pipeline still running	Report in-progress; the gate is not satisfied until jobs finish.
Pipeline needs re-running	Triggers are blocked on git.drupalcode.org — push a commit (--allow-empty if no code change); pipelines fire on push only.
A blocking job failed	Diagnose against the reproduction dev-guide; route back to development → verify.