## Summary A merge request from a fork cannot get a passing pipeline in this project today, not even when a maintainer runs the pipeline in `gitlab-org/labkit`. In that pipeline everything passes, `conformance-spec` included, except `danger-review`, which cannot read its token from Vault. So each fork contribution has to be pushed again to a branch of this project before it can merge: !758 became !760, !767 became !770, and my !768 became !769. Thanks to @M_Alvarez for doing those ports. I'd like to propose a small change to `.gitlab-ci.yml` so that a maintainer-run pipeline for a fork merge request can pass without a port, and, if you want it, so that a contributor's own pipeline in a community fork can pass too. ## What happens today A merge request from a fork gets two kinds of pipeline. **The pipeline in the fork.** Every job inherits `tags: [gitlab-org]` from [`default:`](https://gitlab.com/gitlab-org/labkit/-/blob/cda1964d3ea9df9304c63b320138f3689e88e365/.gitlab-ci.yml#L1-4), no runner in a personal namespace has that tag, and every job ends as `stuck_pending_no_matching_runners`. The [`conformance-spec`](https://gitlab.com/gitlab-org/labkit/-/blob/cda1964d3ea9df9304c63b320138f3689e88e365/.gitlab-ci.yml#L389-400) bridge fails at once with `insufficient_bridge_permissions`, because the labkit-spec pipeline is created as the contributor. That part is expected, and !731 already says that fork merge requests need a member to run the pipeline. **The pipeline a maintainer runs in this project.** Here every job runs on the `gitlab-org` runners and `conformance-spec` passes, but [`danger-review`](https://gitlab.com/gitlab-org/labkit/-/jobs/17112837829) fails before its script starts: ```plaintext Resolving secret "DANGER_GITLAB_API_TOKEN"... Using "vault" secret resolver... ERROR: Job failed: resolving secrets: initializing Vault service: preparing authenticated client: authenticating Vault client: writing to Vault: api error: status code 400: error validating claims: claim "project_id" does not match any associated bound claim values ``` `autolabels` fails the same way, but it is `allow_failure: true`. `danger-review` is not ([`job_allow_failure`](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/bc26ed71a0b2d875e96f681e18c498e912728633/templates/danger/template.yml#L12-15) defaults to `false` and labkit [passes no inputs](https://gitlab.com/gitlab-org/labkit/-/blob/cda1964d3ea9df9304c63b320138f3689e88e365/.gitlab-ci.yml#L37)), so the pipeline fails and the merge is blocked. This follows from how GitLab builds the ID token: in a merge request pipeline its `project_id` claim is the **source** project ([docs](https://gitlab.com/gitlab-org/gitlab/-/blob/7f4f67d95ae3d6a41ef14b1755be75433221ddc2/doc/ci/secrets/id_token_authentication.md#L91), [`jwt.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/7f4f67d95ae3d6a41ef14b1755be75433221ddc2/lib/gitlab/ci/jwt.rb#L13-18)), so for a merge request from a fork it is the fork's ID, whichever project runs the pipeline. The Vault role behind the [danger secret](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/bc26ed71a0b2d875e96f681e18c498e912728633/templates/danger/template.yml#L83-87) refuses it. @M_Alvarez found the same cause in !456 ([note](https://gitlab.com/gitlab-org/labkit/-/merge_requests/456#note_3393144487)). The merge train should hit it too: the train pipeline is [created in the target project](https://gitlab.com/gitlab-org/gitlab/-/blob/7f4f67d95ae3d6a41ef14b1755be75433221ddc2/ee/app/services/merge_trains/create_pipeline_service.rb#L57-62), but the merge request is still from a fork, so `danger-review` would be refused there as well. I'm reading that from the code; I haven't seen a train pipeline for a merge request from a fork here. ## Proposal ### 1. Let `danger-review` fail without blocking on merge requests from forks ```yaml # From the common-ci-tasks danger component. In a merge request pipeline the # ID token's project_id claim is the source project, so for a merge request # from a fork Vault refuses it and DANGER_GITLAB_API_TOKEN cannot be resolved, # whichever project runs the pipeline. Let the job fail there without # blocking the merge. Merge requests from branches of this project keep the # component's own rule. danger-review: rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_SOURCE_PROJECT_ID != $CI_MERGE_REQUEST_PROJECT_ID exists: - Dangerfile allow_failure: true - if: $CI_PIPELINE_SOURCE == "merge_request_event" exists: - Dangerfile ``` The second rule is the [component's rule](https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/bc26ed71a0b2d875e96f681e18c498e912728633/templates/danger/template.yml#L76-79) unchanged. A rule-level `allow_failure` overrides the job-level one only when that rule matches ([docs](https://gitlab.com/gitlab-org/gitlab/-/blob/7f4f67d95ae3d6a41ef14b1755be75433221ddc2/doc/ci/yaml/_index.md#L5789-5790)), and `rules:if` can compare two variables ([docs](https://gitlab.com/gitlab-org/gitlab/-/blob/7f4f67d95ae3d6a41ef14b1755be75433221ddc2/doc/ci/jobs/job_rules.md#L403-406)). In every maintainer-run pipeline for a fork merge request I could find, `danger-review` was the only failing job that was not allowed to fail, so with this rule those pipelines, and the train, should pass with a warning. I haven't been able to run it, since a pipeline from my fork can't. The cost is that Danger's checks do not run at all on a merge request from a fork; today they do, on the ported branch. Those checks would be left to the reviewer for fork merge requests. I'm not suggesting binding the Vault role to `job_project_id` instead: that would hand a GitLab API token to a Dangerfile taken from a fork's branch. client-go uses the same component and avoids this with `job_allow_failure: true` for every merge request ([`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/api/client-go/-/blob/23eb0a84c954e377c956d83f9867e66e77345887/.gitlab-ci.yml#L12-15)). The rule above keeps `danger-review` blocking for branches of this project. The same rule could also live in the component itself, for every project that includes it. ### 2. Optional: skip `conformance-spec` in a fork's own pipeline ```yaml conformance-spec: rules: # The labkit-spec pipeline is created as the user who runs this one. In a # fork's own pipeline that is the contributor, who cannot run pipelines in # labkit-spec, so the bridge can only fail there. Every pipeline that runs # in this project still triggers it, the merge train included. - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_PROJECT_ID != $CI_MERGE_REQUEST_PROJECT_ID when: never - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' changes: !reference [.conformance-trigger-paths, changes] ``` `CI_MERGE_REQUEST_PROJECT_ID` is the project the merge request targets, so the first rule matches only a pipeline that runs somewhere else, which is a fork's own pipeline. This only helps if the rest of a fork's own pipeline can run, which today means a community fork (point 3). The gate stays on every pipeline in this project, and with merge trains enabled the train pipeline still runs it before anything lands. The trade-off: a fork merge request merged without the train, on a green fork pipeline alone, would skip the conformance run. ### 3. Optional: a community fork There is no `gitlab-community` fork of labkit yet. In existing community forks, jobs tagged `gitlab-org` do get runners (for example gitlab-community/gitlab-org/step-runner and gitlab-community/gitlab-org/container-registry run them on the `shared-gitlab-org` runners), so with points 1 and 2 a contributor's own pipeline should be able to pass. A community fork alone does not fix `danger-review`: in the community fork of gitlab-org/api/client-go the job fails with `secrets_provider_not_found` ([example](https://gitlab.com/gitlab-community/gitlab-org/api/client-go/-/jobs/17109677463)) and only gets through because it is allowed to fail. If you want one, I can file the request in gitlab-community/meta and add the "Forks" section its README suggests to `CONTRIBUTING.md`. I'm happy to open the merge request for point 1, and point 2 if you want it. As it touches `.gitlab-ci.yml`, its own pipeline would need a maintainer run like any other fork merge request, and that run would use the changed rules, so it would show whether they work. If it is simpler for you to make the change directly, that works for me too. <details> <summary>Pipelines of !768</summary> | Pipeline | Project | Result | | --- | --- | --- | | [2937946470](https://gitlab.com/jmrp/labkit/-/pipelines/2937946470) (push) | jmrp/labkit | 4 jobs `stuck_pending_no_matching_runners`, the rest skipped | | [2937946705](https://gitlab.com/jmrp/labkit/-/pipelines/2937946705) (merge request) | jmrp/labkit | 14 jobs `stuck_pending_no_matching_runners`, 37 skipped behind `warm-go-mod-cache`, [`conformance-spec`](https://gitlab.com/jmrp/labkit/-/jobs/17106249523) `insufficient_bridge_permissions` | | [2938705386](https://gitlab.com/gitlab-org/labkit/-/pipelines/2938705386) (merge request, run in this project) | gitlab-org/labkit | 50 jobs passed, `conformance-spec` passed ([labkit-spec 2938705566](https://gitlab.com/gitlab-org/quality/tooling/labkit-spec/-/pipelines/2938705566)); failed: [`danger-review`](https://gitlab.com/gitlab-org/labkit/-/jobs/17112837829) and [`autolabels`](https://gitlab.com/gitlab-org/labkit/-/jobs/17112837815) (allowed to fail), both on the Vault error above | </details> <details> <summary>Merge requests from forks since 2025-10-12</summary> Nine merge requests from five forks; none was merged from its fork. Every pipeline run in this project for one of them failed on `danger-review` and `autolabels` and on nothing else: April and May runs report `runner_system_failure`, October runs `runner_configuration_error`, with the same Vault `project_id` error in the log. | Merge request | Pipelines run in this project | Outcome | | --- | --- | --- | | !450 | 3 failed | closed in favour of !498 | | !453 | none | closed as inactive | | !456 | 4 failed | approved and set to merge when checks pass, then closed as inactive | | !457 | none | closed as inactive | | !753 | 1 failed | open | | !754 | none | open | | !758 | 1 failed | ported to !760 (open) | | !767 | 1 failed | ported to !770 (merged) | | !768 | 1 failed | ported to !769 (merged) | The pipelines run in this project: 2487023854, 2487039795, 2491408549, 2498379940, 2501618250, 2515566051, 2557980101, 2919353249, 2926875530, 2938427198, 2938705386. The four from October include `conformance-spec`, and it passed in all four. </details>