A CI fixer that explains the evidence

A failed check starts an investigation

The CI fixer responds to failed checks on pull requests. It receives the failed jobs, steps and available log excerpts, then reads the pull request's code and related tests. Its first job is to decide whether the change caused the failure, whether the test is wrong, or whether the failure is unrelated to the diff. A flaky test, a service outage and a genuine regression need different responses.

For automatic failed-check runs, branch push is off by default and the fix is posted as a comment. An admin or owner can enable the separate “Push the fix to the branch” option. There is also an explicit command path: when the separately enabled Mentions agent accepts @app fix on a failed pull request, that request allows a push even when the automatic CI-fixer switch is off. To evaluate comments only, disable Mentions as well as leaving the CI-fixer push option off. When either push path is active, the fixer can update an eligible same-repository PR branch, including one created by a person. The default branch and fork branches are ineligible. Keep this distinction in mind before choosing the option.

The agent reasons from the logs and files it can read; this workflow's agent environment cannot run the tests itself. A proposed edit therefore needs an independent check. The diagnosis should identify the evidence and the smallest change it supports, or explain why the available information is insufficient. A status that says files changed is not proof that the original failing check is fixed.

Real example: a missing JavaScript parenthesis

Our CI diagnosis on PR #172 is useful precisely because its limits are visible. The bot's comment on 6 November 2026 reported a failing Unit tests step, but the supplied excerpt contained only PostgreSQL service startup and teardown. There was no traceback or test failure block. The agent did not diagnose the original unit-test failure.

While reading the diff, it found a separate syntax problem in infrastudio/static/integrations.js. Removing a conditional wrapper around the Telegram link button had left one closing parenthesis too few. The resulting JavaScript would fail the later Page scripts parse step and prevent the Integrations page from loading. That was a definite code defect, but it was not evidence about what stopped the earlier Python unit tests.

The reported correction added the missing closing parenthesis. A later human-pushed commit bc4e487 included that correction along with other review changes. We do not attribute that push to the CI fixer or claim that its diagnosis solved the original unit-test failure. This summary preserves the distinction between an agent's suggestion and the author's subsequent action.

The comment also asked the author to rerun the unit suite and read the actual failure block. It named environment-sensitive tests as places to inspect, while explicitly saying it had no evidence that those tests failed. This is the right way to handle a partial log: separate the confirmed syntax error from hypotheses about a different failure.

A short tutorial for checking that kind of failure

1. Open the failed workflow at the pull request's exact commit. Find the first failing step and copy its actual error block, not only a service container's logs.
2. Compare the changed file with the base branch. For a JavaScript syntax defect, run node --check infrastudio/static/integrations.js locally after reviewing the proposed edit.
3. Rerun the original failing unit check independently. In this repository that requires a local PostgreSQL test database and the documented unit-test command. A successful JavaScript parse cannot establish that Python tests passed.
4. Push the reviewed correction to the PR branch, then inspect the fresh check results on that commit. If the original failure persists, retain the diagnosis as partial and investigate the new evidence.

These steps describe verification of the example, rather than commands the CI fixer claims to have executed. In another repository, use its documented local checks and dependencies. Avoid changing a test's expectations just to obtain green CI; if a test is wrong, explain the contract it should check and why that contract changed.

Which paths the patch guard blocks

The platform checks changed paths against specific built-in rules and project exclusions, and checks patch size before pushing. For example, the built-in rules block .github/workflows/ci.yml, ops/, Dockerfile, package.json, requirements.txt, migration directories, secrets/project.pem, environment files and agent instruction paths. These are path matches, not a guarantee that every deployment file, dependency manifest or secret location is recognized.

Review your repository layout and add explicit project exclusions for additional sensitive paths. For example, deploy/aws/ and Cargo.toml are not covered by those built-in path rules; exclude them explicitly if they must remain human-only. Auto-merge has separate restrictions, which do not replace the CI-fixer patch guard. A failure requiring a blocked dependency file or workflow change can still receive a diagnosis for a person to handle. Never evaluate a fixer only by how frequently it produces a commit. Check whether its explanation matches the failure and whether it respects the repository's operational boundaries.

Choose diagnosis first, then review permissions

Use an admin or owner account to configure the project. New GitHub projects start with their runner enabled and five event agents on, including the CI fixer. Review or disable those triggers in Agents → Settings on the project card before adding an AI key. If a workspace key already exists, make that activation decision before connecting the repository. A manually added GitLab project needs its runner switched on separately.

Choose a model, leave automatic branch push disabled for the first evaluation, disable Mentions if you want comment-only behavior, and review the attempt limit. The default is two attempts per pull request, with a configurable range of one to five. You can also use Run now with a pull request number as an admin or owner. Inspect both the diagnosis and subsequent CI before deciding whether optional branch pushes suit the team.

Your provider bills the AI tokens used; model choice, log size and repeated attempts affect cost. See platform pricing and security boundaries. CI repair fits after the PR review stage in the analytics-to-pull-request workflow; error triage supplies another source of work. Our dogfooding case shows why successful checks and human review still need to be read together.