I85PREP
⌘ K
GitLab Git Associate study materials
GitLab Git Associate study resources

Fork merge request missing the parent project's integration pipeline

GitLab Git Associate · Put your knowledge to work in context.

All case studies

Fork merge request missing the parent project's integration pipeline

group/api has main protected with allowed-to-merge Maintainers, allowed-to-push No one, two required approvals, and 'Pipelines must succeed'. Developers have the Developer role. A developer forks the project, pushes fix/rate-limit, and opens an MR to group/api:main. The MR shows the fork's pipeline, which runs a linter but skips the integration job because the required CI/CD variables are protected and scoped to group/api. The developer cannot merge. A maintainer asks why the parent project's integration pipeline did not run and whether the fork workflow should be kept for this change. The change touches authentication and must run the integration suite before merge. The fork is in the same top-level group. The project uses merge request pipelines and has no external CI. The developer is not a Maintainer.

1. Diagnose why the integration job did not run in the MR and explain which project's CI/CD configuration, variables, and runners are used for a fork merge request. What are the practical options to get the required suite to run without exposing protected variables?

Read the worked answer

A merge request from a fork runs CI in the fork project, not in group/api. The pipeline uses the fork's copy of .gitlab-ci.yml, the fork's CI/CD variables, and runners available to the fork. Protected variables scoped to group/api are not exposed to the fork, so the integration job either skips or fails. The parent project's pipeline does not automatically run for the fork's branch. This is intentional: otherwise anyone could open a fork MR and exfiltrate protected secrets.

Options:

  1. Create the branch in group/api and open an internal MR. Developers normally may create non-protected branches even when main is protected, so this is the cleanest fix. The MR then uses the parent's variables, runners, and protected-branch approvals.
  2. Keep the fork MR for public review, but do not run secret-dependent integration there. A maintainer can run the trusted suite in the parent project on the MR ref, or the project can use a downstream pipeline that only trusted maintainers trigger.
  3. Do not put protected variables into jobs that fork pipelines can run.

Recommend option 1 for this authentication change, because the integration suite is a merge requirement. Keep the fork workflow for drive-by contributions that do not need secrets.

2. The maintainer suggests lowering the protection to 'Developers can push' so the developer can work in the parent project. Evaluate this against the approval and audit requirements, and propose a safer configuration.

Read the worked answer

Lowering main to 'Developers can push' would let any Developer commit directly to main, bypassing the merge request, the two approvals, and the protected-branch pipeline gate. It solves the developer's branch problem by removing the control that the change is supposed to satisfy. The developer does not need push access to main; they need permission to create a source branch in the parent project.

Safer configuration:

  • Keep main protected with allowed-to-push No one and allowed-to-merge Maintainers.
  • Ensure Developers can create branches. Branch creation is separate from protected-branch push; do not protect * or set a push rule that blocks all branches.
  • Keep the two approval rules, require resolved threads, and require the integration pipeline.
  • If the project uses fork workflows, document that secret-dependent MRs must be opened from a branch in the parent project, or have a maintainer mirror the fork branch into the parent.

Then the developer pushes fix/rate-limit to group/api (not main) and opens the MR. The maintainer reviews and merges. Every change reaches main through an MR with approvals and a parent-project pipeline.

3. Why can't the developer merge even after approvals? Explain the role of allowed-to-merge and approval rules, and what the maintainer should check before merging.

Read the worked answer

Approvals and merge permission are separate. The two required approvals can be satisfied while the Developer still cannot press Merge, because main is protected with allowed-to-merge Maintainers. The Developer role is below Maintainer, so the merge button is disabled or the API returns an authorization error. This is expected, not a bug.

Before merging, the maintainer should check:

  • The approval rule is satisfied and not just 'approved by anyone'; the required approval count is two.
  • The pipeline that counts is the parent project's pipeline on the MR, not a fork pipeline. If the required job was skipped, 'Pipelines must succeed' may still be satisfied depending on the skipped-pipeline setting, so inspect the job status rather than only the badge.
  • All threads are resolved, there are no conflicts, and the source branch is the corrected one.
  • The commit list contains only intended commits; a fork MR with upstream commits should be rebuilt.
  • The change is deployed or rolled back safely.

The maintainer should merge, not ask a Developer to force-merge or lower protection. If the integration suite genuinely cannot run from the fork, move the branch to the parent project first.