Skip to content

skills(running-tend): nightly defers repo-wide CI breakage to tend-ci-fix#3320

Open
worktrunk-bot wants to merge 1 commit into
mainfrom
daily/review-runs-28361631224
Open

skills(running-tend): nightly defers repo-wide CI breakage to tend-ci-fix#3320
worktrunk-bot wants to merge 1 commit into
mainfrom
daily/review-runs-28361631224

Conversation

@worktrunk-bot

Copy link
Copy Markdown
Collaborator

What

Adds a "Session Budget — Don't Chain a Second CI-Fix PR" rule to the nightly reference (.claude/skills/running-tend/references/nightly-cleaner.md).

Why

The nightly run 28357689944 timed out at the hard 3600s session cap (supervisor: status=timeout elapsed=3601s claude_exit=143), which is why it shows as failure with $0.00 / 0 tokens in the token report — the SIGTERM pre-empted the result event.

Reconstructing the session log, the run did productive work and then over-reached:

  1. Opened #3318 (fix(statusline): treat COLUMNS=0 as no width) — merged by the maintainer at 08:58. ✅
  2. While polling fix(statusline): treat COLUMNS=0 as no width, not a zero budget #3318's CI, it noticed code-coverage failing on an apt-install step, correctly traced it to an upstream awalsh128/cache-apt-pkgs-action tag regression ("Packages argument is empty"), and decided to open a second PR to SHA-pin the action across four .github/ sites.
  3. It hit the 3600s timeout git add-ing that second change. The branch fix/ci-cache-apt-pkgs-pin-sha was pushed but no PR was ever opened — the diagnosis and the fix are stranded on an orphan branch.

A repo-wide code-coverage break is squarely tend-ci-fix's job: that workflow triggers on any ci-workflow failure on main, and a failed code-coverage job produces a failure conclusion (non-required is a merge-protection concept, not a workflow-conclusion one). The nightly should have noted the breakage and finished, leaving the fix to the dedicated workflow.

Gate assessment

  • Confidence: this exact shape (nightly hard-timeout from scope-sprawl) is 1 occurrence, but it is a fresh instance of the "work stranded in a one-shot CI session" class that this tracking issue has recorded as High across multiple prior windows (the 2026-06-06 and 2026-06-14 entries — backgrounding the gate + ending the turn, branch never pushed/PR'd). The prior mechanism (backgrounding) was fixed upstream via tend docs: add Windows install guidance #661/refactor(tests): consolidate PTY normalization using insta filters #669; this is the same symptom via a new mechanism (sprawl → hard timeout).
  • Structural vs stochastic: the 3600s cap is structural, and a nightly that surveys → opens a PR → monitors its CI will structurally keep surfacing adjacent repo-wide breakages. The choice to chain a second PR is the stochastic part the rule targets.
  • Change type: small targeted addition; existing running-in-ci "End the turn only when work is shipped" guidance covers the backgrounding variant but not the second-deliverable / hard-timeout variant — this fills that specific gap without duplication.

Note for the maintainer (out of this PR's scope)

The breakage the nightly diagnosed may still be live: ci.yaml and nightly.yaml on main now pin cache-apt-pkgs-action@v1.6.2 (via merged dependabot #3311) while test-setup still pins @v1.6.1. The ready-made fix sits unmerged on fix/ci-cache-apt-pkgs-pin-sha. tend-ci-fix should pick this up on the next failure-concluded main CI run (recent ones were cancelled by rapid pushes, so it kept skipping). Flagging in case you want to open that PR or rerun a clean main build to give tend-ci-fix a trigger.

🤖 Generated by the tend review-runs workflow (run).

…d-ci-fix

Run 28357689944 timed out at the 3600s session cap after shipping #3318
(merged) then chaining a second cache-apt-pkgs-action fix PR, stranding the
branch fix/ci-cache-apt-pkgs-pin-sha (pushed, no PR). Add a nightly-reference
rule: ship the sweep PR, monitor only its CI, and leave unrelated repo-wide
CI breakage to the dedicated tend-ci-fix workflow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@worktrunk-bot worktrunk-bot added the review-runs Findings from the daily review-runs workflow label Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

review-runs Findings from the daily review-runs workflow

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant