GitHub CI Fixer

Fix CI failures by: fetching status → reading logs → reproducing locally → diagnosing → fixing.

Workflow

Step 1: Get PR CI Status

# Get PR checks status
gh pr checks <PR_NUMBER> --repo github/github

# Get detailed workflow runs for PR
gh run list --branch <BRANCH_NAME> --repo github/github --limit 5

# View specific run details
gh run view <RUN_ID> --repo github/github

Step 2: Get Failure Logs

# View failed job logs
gh run view <RUN_ID> --repo github/github --log-failed

# Get specific job logs (if multiple jobs)
gh run view <RUN_ID> --repo github/github --job <JOB_ID> --log

Step 3: Identify Failure Type

Step 4a: Reproduce Test Failures Locally

First, identify the CI environment from the failed job name or logs. Look for GH_CI_RUNTIME in the logs — it shows the build pipeline name (e.g., github-all-features, github-enterprise).

# Run specific test file
bin/rails test <path/to/test_file.rb>

# Run specific test by line number (NEVER use -n flag)
bin/rails test <path/to/test_file.rb>:<LINE_NUMBER>

# Run tests for changed files
bin/rails test:changes

Running in Specific Environments

Match the CI environment when reproducing failures locally:

# Run in Enterprise mode (for github-enterprise builds)
ENTERPRISE=1 bin/rails test <path/to/test_file.rb>

# Run in multi-tenancy/EMU mode (for multi-tenant builds)
MULTI_TENANT_ENTERPRISE=1 bin/rails test <path/to/test_file.rb>

# Run with all features enabled (for github-all-features builds)
TEST_ALL_FEATURES=1 bin/rails test <path/to/test_file.rb>

# Run with all EMU configurations
TEST_WITH_ALL_EMUS=1 bin/rails test <path/to/test_file.rb>

Environment Variable Reference

For additional environment variables, see test/test_helpers/test_env.rb.

Step 4b: Fix Linting Errors

# Auto-fix rubocop issues
bin/rubocop --autocorrect <file.rb>

# Check ERB linting
bin/erb_lint <file.erb> --autocorrect

Step 4c: Fix Type Errors

# Check specific file
bin/srb tc <file.rb>

# Regenerate RBIs if needed
bin/tapioca dsl

Step 5: Diagnose and Fix

For test failures:

1. •Read the failing test to understand expected behavior
2. •Read the source code being tested
3. •Determine if test or source is wrong
4. •NEVER delete a test just because it fails — fix the code or update the test appropriately

For flaky tests:

1. •Look for timing issues, race conditions, or state leakage
2. •Check for missing setup/teardown cleanup
3. •Use gauntlet to reproduce flakiness by running the test many times with database shuffling:

# In your test file - wrap the flaky test with gauntlet
# This creates 100 copies of the test with shuffled DB results
gauntlet "my potentially flaky test", loops: 100 do
  # your test code here
end

Gauntlet options:

• •loops: — number of times to run (default: 100)
• •timeshift: — seconds to shift time between each loop (default: nil)
• •shuffle_database_results: — randomize DB query order to surface flakiness (default: true)
• •debug_output: — print DatabaseShuffler debug info (default: false)

Note: Remove gauntlet wrappers before merging — they're for local debugging only.

Step 6: Verify Fix

# Run the specific failing tests
bin/rails test <test_file.rb>

# Run linting
bin/rubocop <changed_files>

# Run type checking
bin/srb tc <changed_files>

Common CI Jobs

Critical Rules

1. •Never remove tests that fail — propose removal with clear justification for approval
2. •Always reproduce locally before attempting fixes
3. •Run the exact failing test to confirm the fix works
4. •Check if failure is flaky — may need multiple runs to reproduce