Skip to content

Landing queue runbook (ARGUS-342)

When the "MAIN IS RED after landing" page fires

The post-merge net detected the one failure the serial queue cannot prevent: two changes each green alone, broken together. The page names the landing (repo, PR, task, merge sha). Manual revert procedure (deliberately NOT automated yet -- measure first, see /landing/stats.json):

  1. Confirm on the Forgejo commit status page for the named merge sha.
  2. Revert: git revert -m 1 <merge sha> on a branch, PR it, and land it through the queue (POST /landing/{owner}/{name}/ready) -- the revert goes through the same door as everything else.
  3. Reopen the reverted task: POST /tasks/{id}/lifecycle {"to":"ready", ...} and note the break in its why via PATCH.
  4. The counter already recorded the break (post_state=failure). If /landing/stats.json shows post_merge_breaks trending past ~1/month, revisit the bors batching tier (artifact #87's upgrade trigger).

Other failure states

  • failed: rebase conflict -- resolve on the branch, push, re-signal ready.
  • failed: CI failed on the rebased head -- the entry's failing_check/excerpt (ARGUS-572, best-effort via ForgeSource) usually names the red check and a log excerpt right there, so check those before going to Forgejo. Fix, push, re-signal ready.
  • failed: branch kept moving during CI -- stop pushing mid-landing; re-signal when the branch is final.
  • Deploy failed (page from ARGUS-343): the task is HELD unverified; fix the deploy cause and re-enqueue by landing any follow-up PR, or run the hook manually (~/.argus/deploys/<hook>) and satisfy via a re-sweep.