Automate self-workflow re-pin post-cut (obsolete check-self-bootstrap as reminder-for-manual-work) #283

Closed
opened 2026-07-02 13:16:56 +02:00 by bosun · 0 comments
Owner

Motivation

check-self-bootstrap.yml (release-toolkit#124) currently exists as a discipline-backstop: it fires red when the self-workflow uses:@<ref> pins drift from HEAD content, forcing the operator to remember-to-do the re-pin. This is exactly the class of "automated reminder for mechanical work" worth automating away — same shape as release-toolkit#279 (auto-recovery for wrong-target metadata mutations) or release-toolkit#274 (client-side head-ref filter automation).

What to automate

The release-toolkit's own release workflow already does one post-cut mechanical bookkeeping commit — the manifest bump (.release-toolkit-manifest.json update). The self-workflow re-pin fits the same shape:

  • Currently automated: post-cut manifest bump commit
  • This tracker's scope: post-cut self-workflow re-pin commit that updates uses: frankenbit/release-toolkit/...@<ref> in .forgejo/workflows/release.yml + .forgejo/workflows/manifest-check.yml (and any future self-workflow files) to point at the newly-cut tag

Both bookkeeping commits are:

  • Structural (no judgment — always the just-cut tag)
  • Post-tag-creation (new ref available in workflow context)
  • Auth-shared (RELEASE_TOOLKIT_TOKEN path already in use for manifest bump per release-toolkit#273)

Design considerations at pickup

  • Combined commit vs separate: manifest bump + self-workflow re-pin as a single commit (cleaner atomic bookkeeping) vs separate commits (easier revert of one without the other). Lean single-commit for atomicity.
  • Race with subsequent PR merges: if new work lands between cut + auto-re-pin, ordering matters. Likely handled by same mechanism as manifest bump.
  • Path-α vs path-γ split: whichever path handles manifest bump handles re-pin (same infrastructure).
  • Backwards-compat with check-self-bootstrap: keep the check as fail-safe (it only fires when automation breaks); do not delete it.

Post-automation behavior

  • check-self-bootstrap becomes an unused guardrail in normal operation
  • It fires only when automation fails → distinct signal ("automation broke" vs current "operator forgot")
  • Cleaner separation of concerns: automation does the work, check exists as fail-safe

Bridge until automation lands

Manual re-pin PR for v0.19.x → v0.20.0 (post-2026-07-02 cut, current instance of the discipline gap). Fresh mechanical PR, closes the current failure. QM handles as part of Set E toil-drain.

Refs

  • Sibling automation tracker: release-toolkit#279 (auto-recovery for wrong-target metadata mutations)
  • Discipline backstop being obsoleted: release-toolkit#124 (self-bootstrap re-pin discipline)
  • Auth substrate: release-toolkit#273 (RELEASE_TOOLKIT_TOKEN provisioning)
  • Empirical anchor: check-self-bootstrap firing on release-toolkit#264 and every PR post-cut 2026-07-02

Anchor

Operator surfaced 2026-07-02 in Set E setup discussion: "sounds like an automated invitation / reminder for manual work. Wouldn't it make sense (if it would be possible) to automate the work and skip the reminder in the shape of a CI run failure?"

## Motivation `check-self-bootstrap.yml` (release-toolkit#124) currently exists as a discipline-backstop: it fires red when the self-workflow `uses:@<ref>` pins drift from HEAD content, forcing the operator to remember-to-do the re-pin. This is exactly the class of "automated reminder for mechanical work" worth automating away — same shape as release-toolkit#279 (auto-recovery for wrong-target metadata mutations) or release-toolkit#274 (client-side head-ref filter automation). ## What to automate The release-toolkit's own release workflow already does one post-cut mechanical bookkeeping commit — the manifest bump (`.release-toolkit-manifest.json` update). The self-workflow re-pin fits the same shape: - **Currently automated**: post-cut manifest bump commit - **This tracker's scope**: post-cut self-workflow re-pin commit that updates `uses: frankenbit/release-toolkit/...@<ref>` in `.forgejo/workflows/release.yml` + `.forgejo/workflows/manifest-check.yml` (and any future self-workflow files) to point at the newly-cut tag Both bookkeeping commits are: - Structural (no judgment — always the just-cut tag) - Post-tag-creation (new ref available in workflow context) - Auth-shared (RELEASE_TOOLKIT_TOKEN path already in use for manifest bump per release-toolkit#273) ## Design considerations at pickup - **Combined commit vs separate**: manifest bump + self-workflow re-pin as a single commit (cleaner atomic bookkeeping) vs separate commits (easier revert of one without the other). Lean single-commit for atomicity. - **Race with subsequent PR merges**: if new work lands between cut + auto-re-pin, ordering matters. Likely handled by same mechanism as manifest bump. - **Path-α vs path-γ split**: whichever path handles manifest bump handles re-pin (same infrastructure). - **Backwards-compat with check-self-bootstrap**: keep the check as fail-safe (it only fires when automation breaks); do not delete it. ## Post-automation behavior - `check-self-bootstrap` becomes an unused guardrail in normal operation - It fires only when automation fails → distinct signal ("automation broke" vs current "operator forgot") - Cleaner separation of concerns: automation does the work, check exists as fail-safe ## Bridge until automation lands Manual re-pin PR for v0.19.x → v0.20.0 (post-2026-07-02 cut, current instance of the discipline gap). Fresh mechanical PR, closes the current failure. QM handles as part of Set E toil-drain. ## Refs - Sibling automation tracker: release-toolkit#279 (auto-recovery for wrong-target metadata mutations) - Discipline backstop being obsoleted: release-toolkit#124 (self-bootstrap re-pin discipline) - Auth substrate: release-toolkit#273 (RELEASE_TOOLKIT_TOKEN provisioning) - Empirical anchor: check-self-bootstrap firing on release-toolkit#264 and every PR post-cut 2026-07-02 ## Anchor Operator surfaced 2026-07-02 in Set E setup discussion: "sounds like an automated invitation / reminder for manual work. Wouldn't it make sense (if it would be possible) to automate the work and skip the reminder in the shape of a CI run failure?"
bosun closed this issue 2026-07-02 16:00:50 +02:00
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
frankenbit/release-toolkit#283
No description provided.