GitLab Next

Summary

Customers want to use the "Pipelines must succeed" button to enforce a policy that a commit must pass its tests before it can be merged. But it's possible for developers to bypass the policy entirely using CI skipping.

Steps to reproduce

1. Create a new project with a README and a simple .gitlab-ci.yml (see below)
2. Turn on "Pipelines must succeed"
3. Protect the master branch and set "Allowed to Push" to "No One" for master
4. Create a branch and MR
5. In your branch, edit exit 0 to say exit 1 (which is a failure)
6. Commit your change with "[skip ci]" as the commit message
7. Push your change
8. Navigate to the Merge Request. The merge button appears, and it's possible to merge - even though you just broke the build and insisted that Pipelines must succeed.

Here's a CI configuration that will work:

test:
  script:
    - exit 0
  only: ['merge_requests']

Example Project

https://gitlab.com/fpotter/examples/skip-ci

Note While in the steps above I use the [skip ci] commit message, I assume (have not tested) that the ci.skip push option would similarly allow a developer to bypass the pipeline success requirement.

What is the current bug behavior?

The Merge button appears in the MR. It can be merged. Even though you set a policy that pipelines must succeed, and the build is completely broken.

What is the expected correct behavior?

A message that says something like:

The pipeline for this merge request was skipped. Please run a successful pipeline on this branch.

The format could be the same as is currently shown when the Pipeline is blocked or failed (see below).

Relevant logs and/or screenshots

The "Pipelines must succeed" button:

The "Merge" button that appears:

The "Blocked" message, which indicates a possible format for the "skipped" message:

The "Failed" message, also to indicate format:

Output of checks

This bug happens on GitLab.com.

Possible fixes

?

Customer impact

Major issue for at least one enterprise customer

/cc @jlenny @williamchia @dhavens @jmiklos