# Ensure CI pipeline passes before merge

- Source: https://support.icompaas.com/support/solutions/articles/a_1781201610848224-ensure-ci-pipeline-passes-before-merge
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Version Control System (VCS)](https://support.icompaas.com/support/solutions/c_1781179095087930) › [GitHub](https://support.icompaas.com/support/solutions/folders/f_1781179116560328)
- Last updated: 2026-10-16
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:

This check verifies that GitHub is configured to require successful completion of CI/CD pipeline checks before pull requests can be merged into the protected default branch. CI pipelines typically perform automated build validation, testing, security scanning, and quality checks.

  

Rationale:

CI pipelines help ensure that code changes are validated before being integrated into the main codebase. Requiring successful pipeline execution before merge reduces the risk of introducing defective, insecure, or untested code into production branches.

  

Impact:

Enforcing CI pipeline requirements may:

-   Prevent pull requests from being merged when pipeline execution fails.
    
-   Increase merge times while pipeline jobs complete.
    
-   Improve code quality and software reliability.
    
-   Reduce production incidents caused by untested changes.
    

  

Default Value:

Disabled

By default, GitHub does not require CI pipeline checks before pull requests can be merged. Repository administrators must explicitly configure rulesets or branch protection rules and select the CI workflow checks to be enforced.

  

Remediation:

Test Plan:

1.  Log in to GitHub with access to the repository.
    
2.  Navigate to Settings → Rules → Rulesets.
    
3.  Open the ruleset applied to the default branch.
    
4.  Verify that Require status checks to pass is enabled.
    
5.  Verify that at least one status check is listed under Required checks.
    
6.  Review the configured checks (for example, GitHub Actions workflows).
    
7.  Create a test pull request with a failing status check.
    

  

Implementation:

Create or configure a GitHub Actions workflow in:  
.github/workflows/

1.  Log in to GitHub with access to the repository.
    
2.  Ensure the workflow runs successfully at least once and generates a status check.
    
3.  Navigate to Settings → Rules → Rulesets.
    

4.  Edit the ruleset or create new ruleset
    
5.  Enter a meaningful ruleset name Set Enforcement Status to Active.Under Target Branches, click Add Target. And select include all branches
    

6.  Enable:
    

-   Require status checks to pass
    

8.  Click Add checks.
    
9.  Select one or more status checks, such as:
    

-   Maven Build
    
-   Unit Tests
    
-   Security Scan
    
-   CodeQL Analysis
    

9.  Save the ruleset.
    

  

Backout Plan:

1.  Log in to GitHub with repository administrator privileges.
    
2.  Navigate to Settings → Rules → Rulesets.
    
3.  Edit the ruleset protecting the default branch.
    
4.  Disable Require status checks to pass or remove the configured required checks.
    
5.  Save the changes.
    
6.  Confirm repository operations function as expected after rollback.
    

  

References:

-   [https://docs.github.com/en/actions](https://docs.github.com/en/actions)
    
-   [https://docs.github.com/en/actions/using-workflows/about-workflows](https://docs.github.com/en/actions/using-workflows/about-workflows)
    
-   [https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)
    
-   [https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/about-protected-branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/about-protected-branches)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.