Pull Requests with Failing CI/CD Checks

This compliance check detects pull requests that were merged despite having failing CI/CD status checks. Merging with failures can introduce broken code, security vulnerabilities, or untested changes to production.

What It Detects

Dike examines the CI/CD status check rollup from the last commit in a merged PR. If the overall build status is FAILURE or ERROR, a violation is created.

Scenarios that trigger violations:

• PR merged with failing unit tests
• PR merged with security scan failures
• PR merged with lint/code quality errors
• PR merged with integration test failures

Examples of compliant PRs:

• All CI checks passing (SUCCESS status)
• PR merged after fixing failing checks
• Checks pending but eventually pass (evaluated at merge time)

The check uses GitHub's status check rollup, which aggregates all configured status checks (GitHub Actions, third-party CI, etc.) into a single state.

Why It Matters for SOC2

Merging code with failing checks undermines the integrity of your CI/CD pipeline and violates several SOC2 controls:

• CC6.8 - Preventing Unauthorized Changes: CI/CD checks are a control mechanism. Bypassing them means untested or non-compliant code can reach production.
• CC7.1 - System Integrity: Production systems must maintain integrity. Failing checks may indicate security vulnerabilities, breaking changes, or quality issues.
• CC7.2 - Change Testing: All changes should be tested before deployment. Failing checks explicitly indicate tests did not pass.
• CC8.1 - Risk Assessment: Merging with failures introduces known risk without proper assessment.

This check provides evidence that your team takes CI/CD results seriously and doesn't bypass safety mechanisms.

How to Resolve Violations

Immediate Resolution

1. Review the failure: Identify why checks failed and assess the impact.

2. Create a follow-up fix: If the failure was genuine:

   git checkout main
   git checkout -b fix/PROJ-123-fix-broken-tests
   # Make fixes
   git push origin fix/PROJ-123-fix-broken-tests

3. Acknowledge if intentional: Sometimes failures are acceptable:

   • Flaky tests being addressed separately
   • Non-blocking advisory checks
   • Known issues with workarounds in place

4. Document the decision: Add a comment explaining why the merge was allowed despite failures.

Preventive Measures

• Require status checks: Configure GitHub branch protection to require checks to pass before merging.
• Block admin bypass: Prevent repository admins from bypassing required checks.
• Fix flaky tests: Regularly address intermittent test failures to maintain trust in the CI pipeline.
• Review check configuration: Ensure important checks are marked as required, not optional.

Configuration Options

Rule Configuration

name: PR merged with failing build
trigger: pr_merged
status: enabled
priority: high
conditions:
  - type: build-status
    operator: equals
    value: failure
actions:
  - type: create-violation
    severity: high
branchPatterns: []

Configurable Parameters

Parameter	Description	Default
value	Status to check: failure, error, success, pending	failure
operator	Comparison: equals, not-equals	equals
severity	Violation severity level	high
branchPatterns	Target branches (empty = all)	[]
status	Rule status: enabled, disabled, warning	disabled
priority	Rule priority for ordering	high

Status Values

GitHub provides these rollup status values:

Status	Meaning
SUCCESS	All checks passed
FAILURE	One or more checks failed
ERROR	Check execution error
PENDING	Checks still running

Multiple Status Checks

To flag PRs merged with any non-success status:

conditions:
  - type: build-status
    operator: not-equals
    value: success

Branch-Specific Configuration

Apply stricter rules to production branches:

branchPatterns:
  - main
  - master
  - release/*
  - production

Metadata Captured

When a violation is created, Dike captures:

• Build status at merge time
• Last commit SHA
• Individual check context details (check names, statuses)
• PR number and merge timestamp

This information helps teams investigate why the PR was merged and which checks failed.

Related Checks

• PRs Without Approvals - Another merge-time quality gate
• Direct Commits to Main - Commits that bypass PR process entirely