Skip to content

Evergreen: always merge main first, then fix CI #266

@mrjf

Description

@mrjf

Current behavior

Evergreen checks for two issue types independently:

  • merge_conflict — merges main into the PR branch
  • failing_checks — fixes the code without merging main first

This causes push_to_pull_request_branch failures when the agent merges main locally (to understand the current state) but the incremental patch includes the merge commit, which conflicts with the remote PR branch that hasn't been merged yet.

Desired behavior

Every Evergreen run should follow this sequence:

  1. Check out the PR branch
  2. If main is ahead, merge main into the PR branch first — resolve any conflicts, get the branch up to date, push the merge
  3. Then check if CI passes — if not, fix the failing checks and push the fix

This is two separate pushes when both are needed:

  • First push: the merge commit (gets the branch current with main)
  • Second push: the CI fix (on top of the merged branch)

This avoids the patch conflict problem because each push is clean — the merge commit goes on top of the remote branch state, and the fix commit goes on top of the merged state.

Why this matters

Autoloop PRs accumulate iterations while main moves forward. The PR branch falls behind, and CI often fails because of drift (not because the iteration itself is broken). Merging main first often fixes CI on its own. When it doesn't, the agent has the full current codebase to work with when diagnosing the failure.

Changes needed

  1. Evergreen selector (pr_needs_attention): also flag PRs that are behind main (add a behind_main issue type)
  2. Evergreen prompt (Workflow section): restructure the fix flow:
    • Step 1: Always merge main if behind
    • Step 2: Push the merge via push_to_pull_request_branch
    • Step 3: Check if CI is still failing after the merge
    • Step 4: If still failing, diagnose and fix, push again
  3. Evergreen prompt (Rules section): explicitly state "do NOT merge main inside a CI-fix patch — that's a separate push"

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions