fix(release): tag only, before the cutover fires this for the first time #14

wtclaude · 2026-08-05T22:19:06Z

wtclaude commented

2026-08-05 22:19:06 +00:00

What & why

The same two faults as link#28, in the copy this repo's workflow was forked from — except this one has never run at all. The edge → main cutover would have been its first execution, on the release that matters most.

An empty template expression in a comment makes the runner fail to build the "Commit version bump and push tag" step and skip it without failing the job. link carried that through six releases: its Cargo.toml still says 0.1.0 while its tags reach v1.1.1, because Gitea's release API creates the tag when it publishes. A green run proves nothing about a step that was never built.
The step pushes to main, which is protected. The bundle job proved that today — pre-receive hook declined, twice. A first release must not depend on a write to a protected branch.

So: the tag is the version, as in servuo-plugins, whose tag pushes are proven against this protection. The version is still written into Cargo.toml before building, so a released binary self-reports correctly; it is simply not committed back. The next version is computed from the newest tag, never from the file.

Also corrected: the prerequisites header stated that main must accept a direct push from the CI user ("disable branch protection for it, or add it as an exception"). It does not, and it should not — that line is replaced with the reason. The if: guard against looping on a bump commit is kept but labelled vestigial.

How it was tested

release.yml parses, and grep -c '\${{ *}}' is 0 for this file. The logic below the removed commit — tag reuse and the tag push — is unchanged.

The honest limit is the same as link#28's: a release workflow is only really proven by a release. The difference here is that this one is about to get its first, and the failure it was heading for — a push rejected after the artifacts were built — is exactly the kind that leaves a half-published state.

link#28 — the identical fix in the repo this was forked from.
installer#13 — the same comment bug had silently disabled the bundle CI's stale-component dispatch, plus the branch-protection fix that moves bundles to their own branch.

Checklist

I have read CONTRIBUTING.md.
The change builds and existing tests/checks pass locally.
I have added or updated tests/docs where it makes sense.
My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

No AI tools were used to produce this contribution.
AI tools were used. Tool(s): Claude Code (Opus 5). I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a Co-Authored-By trailer.

License

I agree that my contribution is licensed under this project's license (GNU GPL v3.0 or later), and I have the right to contribute it.

## What & why The same two faults as link#28, in the copy this repo's workflow was forked from — except **this one has never run at all**. The `edge → main` cutover would have been its first execution, on the release that matters most. 1. **An empty template expression in a comment** makes the runner fail to build the *"Commit version bump and push tag"* step and skip it *without failing the job*. `link` carried that through six releases: its `Cargo.toml` still says `0.1.0` while its tags reach `v1.1.1`, because Gitea's release API creates the tag when it publishes. A green run proves nothing about a step that was never built. 2. **The step pushes to `main`, which is protected.** The bundle job proved that today — `pre-receive hook declined`, twice. A first release must not depend on a write to a protected branch. So: the tag is the version, as in `servuo-plugins`, whose tag pushes are proven against this protection. The version is still written into `Cargo.toml` before building, so a released binary self-reports correctly; it is simply not committed back. The next version is computed from the newest tag, never from the file. Also corrected: the prerequisites header stated that **`main` must accept a direct push from the CI user** ("disable branch protection for it, or add it as an exception"). It does not, and it should not — that line is replaced with the reason. The `if:` guard against looping on a bump commit is kept but labelled vestigial. ## How it was tested `release.yml` parses, and `grep -c '\${{ *}}'` is `0` for this file. The logic below the removed commit — tag reuse and the tag push — is unchanged. The honest limit is the same as link#28's: a release workflow is only really proven by a release. The difference here is that this one is about to get its first, and the failure it was heading for — a push rejected after the artifacts were built — is exactly the kind that leaves a half-published state. ## Related - link#28 — the identical fix in the repo this was forked from. - installer#13 — the same comment bug had silently disabled the bundle CI's stale-component dispatch, plus the branch-protection fix that moves bundles to their own branch. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [ ] No AI tools were used to produce this contribution. - [x] AI tools were used. Tool(s): `Claude Code (Opus 5)`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.

wtclaude added 1 commit 2026-08-05 22:19:07 +00:00

fix(release): tag only, before the cutover fires this for the first time

PR Checks / rust-gates (pull_request) Successful in -35s

Details

ea7e491ba3

The same two faults link/release.yml has, in the copy this repo was
forked from -- and this one has never run at all, so the cutover would
have been its first execution.

An empty template expression written literally in a comment makes the
runner fail to build the "Commit version bump and push tag" step and
skip it WITHOUT failing the job. link carried that for six releases,
which is why its Cargo.toml still says 0.1.0 while its tags reach
v1.1.1; the tags exist because the release API creates one when it
publishes.

And the step pushes to main, which is protected -- the bundle job
proved that today with `pre-receive hook declined`. A first release
must not depend on a write to a protected branch.

So the tag is the version, as in servuo-plugins. The version is still
written into Cargo.toml before building, so a released binary
self-reports correctly; it is simply not committed back.

The prerequisites header said `main` must accept a direct push from the
CI user. It does not, and it should not; that line is replaced with the
reason.

Co-Authored-By: Claude <noreply@anthropic.com>

PR Checks / rust-gates (pull_request) Successful in -35s

Required

Details

This pull request doesn't have enough required approvals yet. 0 of 1 approvals granted from users or teams on the allowlist.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin fix/release-tag-only-installer:fix/release-tag-only-installer

git checkout fix/release-tag-only-installer

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/installer#14