FAQ | This is a LIVE service | Changelog

Skip to content

Record a decision on MR pipeline support

Description

Record the discussion and a decision on how/if we support merge request pipelines going forward.

Further details

We currently include the AutoDevOps pipeline via:

include:
  - template: Auto-DevOps.gitlab-ci.yml

The actual template is just composed of two parts: a workflow configuration and includes for various job templates.

  • The workflow rules enable/disable the entire workflow based on the presence of files in the repo. For our needs this is often the Dockerfile file.
    • For example, with some libraries, this causes a bit of a pain since we need to "force enable" AutoDevOps to get pipelines to run at all.
  • The individual jobs, e.g. the dependency scanning job, futher restrict themselves to pipelines where CI_COMMIT_BRANCH is defined. This effectively disables them for all except "push" pipelines.

The jobs in our pre-commit and python templates, by contrast, work hard to enable themselves on push pipelines only when there is not a merge request open. In that case they run on the merge request pipeline.

The "merge request pipeline" is always triggered for an open Merge Request. The "Enable merged results pipelines" setting in a GitLab project's settings has no effect.

When a "merge request pipeline" runs, it "wins" insofaras its success or failure determines whether the Merge Request can be merged.

So we have an issue: our common CI jobs such as pre-commit or Python tox tests run in a merge request pipeline and take steps to disable themselves in a branch pipeline if a merge request is open. The Auto DevOps jobs run in a branch pipeline and do not run in a merge request pipeline.

Since the MR pipeline "wins", we can have strange behaviours (https://gitlab.developers.cam.ac.uk/uis/devops/iam/identity/identity-system/-/merge_requests/14) where the "build" job can fail in the branch pipeline but the MR is still marked as green since the merge request pipeline succeeded.

We have two things to decide:

  • Do we keep the workflow rules defined in the Auto DevOps template or move to one of the GitLab supplied templates as recommended in the docs.
  • Do we mandate that all jobs we add to this repo run only in branch pipelines and not in MR pipelines or do we try customising the various security scanning jobs?

Task list

  • Agree an approach.
  • Document that approach as an Architecture Decision Record providing a summary of the context and a rationale.
  • Open issues to implement the agreed approach (if necessary).

Acceptance criteria

  • MR opened with decision record.
  • MR opened with any implementation changes.

Links/references