Repository navigation
Description
Finding
In .github/workflows/auto-format.yml, the workflow-only early exit introduced by PR #3198 never records success, so the AUTO_FORMAT_LAST_SUCCESS_SHA fast path never engages after a workflow-only head.
PR #3198 (merged 5018339, for #3118) partitioned changed files into format_files / skipped_workflow_files and added this branch:
if ((${#format_files[@]} == 0)); then
echo "Only workflow files changed; nothing for the auto-format bot to push."
exit 0
fiThe 2026-11-02 scheduled redesign added record_success (which stores the current HEAD in the repo variable AUTO_FORMAT_LAST_SUCCESS_SHA) to every other terminal success path in the same run block — verified on current main (two independent reads of the file via the contents API, full text + grep):
- no changed files →
record_successthen exit (lines 93–94) - treefmt made no changes →
record_successthen exit (lines 122–123) - after a successful push →
record_success(line 142) - workflow-only branch → plain
exit 0(line 115), norecord_success
Why it matters
The workflow header states the design intent: "a run whose HEAD still equals it [LAST_SUCCESS_SHA] exits immediately". After any merge whose changed-file range is workflow-only, that never happens: every 15-minute scheduled run re-checks out the repo, installs Nix, re-diffs the same range, and re-logs the same skipped workflow files, until an unrelated non-workflow change happens to land and a later branch records success. The variable is documented as an optimization rather than a correctness input, so nothing breaks — it is pure recurring CI burn (up to 96 scheduled runs/day) plus noisy duplicate "Skipping workflow file(s)" logs that make the skip look unhandled.
Acceptance criteria
- The workflow-only branch calls
record_successbefore exiting (or an equivalent advance ofAUTO_FORMAT_LAST_SUCCESS_SHA), matching the other no-op success branches. - A subsequent scheduled run with an unchanged HEAD takes the "main is unchanged since the last successful format pass" fast path.
- Workflow files are still never formatted/staged by the bot (the fix(ci): auto-format push is rejected when the format diff touches workflow files (PR #2148) #3118 behavior PR fix(ci): prevent workflow format diffs from blocking auto-format push (#3118) #3198 added is unchanged), and the skipped files are still logged on the run that first sees them.
- The existing
scripts/tests/test_auto_format_workflow.pycoverage for the workflow-only exit still passes, ideally extended to assert the success recording.
Found by the pr-diff-review job reviewing PR #3198 (batch #3190–#3217, developing-today/code). Deduped: #3118 (closed) is the original push-rejection bug this branch fixed; no open or closed issue mentions record_success or the workflow-only stall.
Activity
dezren39 commentedon Nov 3, 2026
🤖 Agent note · filed
dezren39 commentedon Nov 3, 2026
🤖 Agent note · claimed
7 remaining items
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 3, 2026
🤖 Agent note · claimed
dezren39 commentedon Nov 3, 2026
🤖 Agent note · PR opened
record_successbefore the workflow-onlyexit 0; the workflow-file skip exclusion and logging are unchanged.python3 -I scripts/tests/test_auto_format_workflow.py— 4 tests pass (workflow-only recording + unchanged-HEAD fast path added; harnessGITHUB_REPOSITORYgap fixed).Merge pull request #4755 from developing-today/queue/6748-4752-auto-f…
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
29a8907f76c6c837a704498197a73ba0a90a9590): workflow-only auto-format pass callsrecord_successbefore exiting. Issue auto-closed.python3 -I scripts/tests/test_auto_format_workflow.py4/4 passed.