daniel/gitdan-actions
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

ci: nothing moves the v1 tag, so a merged change is inert until retagged by hand #27

New Issue
Closed
opened 2026-09-22 16:12:32 +00:00 by claude · 1 comment
claude commented 2026-09-22 16:12:32 +00:00
Collaborator
Copy Link
Copy Source

Problem

Every consumer pins the floating major tag — uses: https://gitdan.com/daniel/gitdan-actions/cargo-cache@v1 (README.md:120, :131, :136, and the same form in daniel/zemyna's .gitea/workflows/ci.yaml). Nothing moves v1 when main advances, so a merged change is inert until someone remembers to retag by hand.

It happened on 2026-09-22: PR #25 merged to main at 21dffdb, v1 stayed at 0184df2 (the #21 merge), and the fix was live nowhere. It was caught by the user asking whether the tag had been repointed — not by anything in the repo. The tag was then force-updated by hand.

That the previous merge's retag did happen only makes it worse as a process: the convention exists, produces no artifact, and is invisible when skipped. A merge that silently does nothing is the failure mode — CI stays broken in exactly the way the merge was supposed to fix, and the next person debugs the symptom rather than the release.

What exists today

.gitea/workflows/ contains only ci.yaml. There is no release workflow, and the README documents how consumers pin @v1 (README.md:120) without saying anywhere how v1 advances.

Options

  1. A release workflow that fast-forwards v1 to main on every push to main, after the gate is green. Removes the human step entirely. Needs a token with tag-push rights and needs to force-update the ref, which is what a floating major tag means.
  2. A gate that fails when v1 lags main, leaving the retag manual but impossible to forget silently. Cheaper and less privileged than option 1, at the cost of still needing a human.
  3. Document it in the README beside the @v1 usage. Weakest — the convention already existed and was skipped anyway.

Option 1 is the correct-by-construction one; option 2 is the cheap one that at least makes the omission loud. Option 3 alone does not address what actually failed.

Acceptance criteria

  1. A merge to main either moves v1 automatically, or produces a loud, unmissable failure while v1 lags.
  2. Whichever is chosen, the mechanism is documented next to the @v1 usage in README.md so a consumer can see how releases work.
  3. Verified on a real merge — not only by reading the workflow.

Notes

  • Consider whether v1 should be an annotated tag carrying the release, rather than a lightweight ref force-moved in place. That is a larger convention question and shouldn't block the immediate fix.
  • Whatever lands must keep the property that consumers can pin a stable major and get reviewed changes only. Pointing consumers at @main would remove this problem and the pin's value together, so it is not the answer.
## Problem Every consumer pins the floating major tag — `uses: https://gitdan.com/daniel/gitdan-actions/cargo-cache@v1` (README.md:120, :131, :136, and the same form in `daniel/zemyna`'s `.gitea/workflows/ci.yaml`). Nothing moves `v1` when `main` advances, so **a merged change is inert until someone remembers to retag by hand.** It happened on 2026-09-22: PR #25 merged to `main` at `21dffdb`, `v1` stayed at `0184df2` (the #21 merge), and the fix was live nowhere. It was caught by the user asking whether the tag had been repointed — not by anything in the repo. The tag was then force-updated by hand. That the previous merge's retag *did* happen only makes it worse as a process: the convention exists, produces no artifact, and is invisible when skipped. A merge that silently does nothing is the failure mode — CI stays broken in exactly the way the merge was supposed to fix, and the next person debugs the symptom rather than the release. ## What exists today `.gitea/workflows/` contains **only** `ci.yaml`. There is no release workflow, and the README documents how consumers pin `@v1` (README.md:120) without saying anywhere how `v1` advances. ## Options 1. **A release workflow** that fast-forwards `v1` to `main` on every push to `main`, after the gate is green. Removes the human step entirely. Needs a token with tag-push rights and needs to force-update the ref, which is what a floating major tag means. 2. **A gate that fails when `v1` lags `main`**, leaving the retag manual but impossible to forget silently. Cheaper and less privileged than option 1, at the cost of still needing a human. 3. **Document it** in the README beside the `@v1` usage. Weakest — the convention already existed and was skipped anyway. Option 1 is the correct-by-construction one; option 2 is the cheap one that at least makes the omission loud. Option 3 alone does not address what actually failed. ## Acceptance criteria 1. A merge to `main` either moves `v1` automatically, or produces a loud, unmissable failure while `v1` lags. 2. Whichever is chosen, the mechanism is documented next to the `@v1` usage in `README.md` so a consumer can see how releases work. 3. Verified on a real merge — not only by reading the workflow. ## Notes - Consider whether `v1` should be an annotated tag carrying the release, rather than a lightweight ref force-moved in place. That is a larger convention question and shouldn't block the immediate fix. - Whatever lands must keep the property that consumers can pin a *stable* major and get reviewed changes only. Pointing consumers at `@main` would remove this problem and the pin's value together, so it is not the answer.
claude added the bug label 2026-09-22 16:12:32 +00:00
claude commented 2026-09-22 23:15:15 +00:00
Author
Collaborator
Copy Link
Copy Source

AC3 verified on a real merge. PR #28 merged as 0284fcd, and its own release-tag job ("move v1 to main") succeeded on that merge: refs/tags/v1 moved from 21dffdb to 0284fcd with no manual step. The same run also confirms the workflow token can push a tag to this repository.

**AC3 verified on a real merge.** PR #28 merged as `0284fcd`, and its own `release-tag` job ("move v1 to main") succeeded on that merge: `refs/tags/v1` moved from `21dffdb` to `0284fcd` with no manual step. The same run also confirms the workflow token can push a tag to this repository.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is broken or not working as intended
 docs-drift-catalog
The standing per-repo catalog of known stale documentation and comments.
 enhancement
New feature or improvement
 question
Further information is requested
No labels bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
claude claude-reviewer codex codex-reviewer daniel (Daniel Lynn)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: daniel/gitdan-actions#27