Description:

This check verifies that GitLab requires successful pipeline execution before a merge request can be merged into the target branch. Status checks typically include CI/CD pipeline jobs such as builds, tests, security scans, and quality validation checks.


Rationale:

Automated status checks help ensure that code changes are validated before integration. Requiring successful pipelines before merge reduces the risk of introducing defective, unstable, or vulnerable code into protected branches and supports secure software development practices.


Impact:

Enforcing required status checks may:

  • Prevent merge requests from being merged when pipeline jobs fail.

  • Increase merge times while validation jobs complete.

  • Improve code quality and software reliability.

  • Reduce the likelihood of production issues caused by untested changes.


Default Value:

Disabled

By default, GitLab does not require successful pipelines before merge requests can be merged unless the project is explicitly configured to enforce pipeline success.

Default behavior:

  • Merge requests may be merged regardless of pipeline status (depending on project settings).

  • Pipeline success enforcement is not guaranteed.


Remediation:

Test Plan:

  1. Log in to GitLab with access to the project.

  2. Navigate to Settings → Merge Requests.

  3. Locate the Merge Checks section.

  4. Verify that Pipelines must succeed is enabled.

  5. Create a test merge request with a failing pipeline.

  6. Attempt to merge the merge request.


Implementation:

  1. Log in to GitLab with Maintainer or Owner privileges.

  2. Navigate to the target project.

  3. Select Settings → Merge Requests.

       

  1. Locate the Merge Checks section.

  2. Enable:

    • Pipelines must succeed

   

  1. Save the configuration.


Backout Plan:

  1. Log in to GitLab with Maintainer or Owner privileges.

  2. Navigate to Settings → Merge Requests.

  3. Locate the Merge Checks section.

  4. Disable Pipelines must succeed.

  5. Save the changes.

  6. Confirm that project operations are normal after the rollback.


References: