fix(release): tag only, and stop pushing to main #28

wtclaude · 2026-08-05T22:17:25Z

wtclaude commented

2026-08-05 22:17:25 +00:00

What & why

The "Commit version bump and push tag" step had two problems, and the first hid the second.

It has never once executed

An empty template expression written literally in one of its comments makes the runner fail to build the step's script — and a step it cannot build is skipped without failing the job:

Unable to interpolate expression 'format('…', steps.plan.outputs.version, steps.plan.outputs.tag, )':
Failed to parse: unexpected token ")"

That is why sidecar/Cargo.toml still says 0.1.0 after six releases, and why the tag-reuse handling added in #27 was dead on arrival. The tags exist because Gitea's release API creates one when it publishes — this pipeline has been working by accident, and nobody could have noticed from a green run.

And had it executed, it would have been declined

main is protected: the pre-receive hook rejects the push. The installer's bundle job hit exactly that today, twice. A release must not depend on a write to a protected branch.

So: the tag is the version

Which is already how servuo-plugins works — that workflow was written this way on purpose ("Tag only — no bump commit, so main is never pushed to") and is the one release workflow in the org that has never needed a protection exception. Its tag pushes are proven against this same protection:

git push origin "${TAG}"
 * [new tag]         v0.2.0 -> v0.2.0

The workflow still writes the real version into Cargo.toml before building, so a released binary self-reports correctly; what it no longer does is commit that edit back. Nothing downstream reads the file — the next version is computed from the newest tag, and CARGO_VERSION is consulted only when no tag exists at all.

The comment is reworded so the step can actually run, and warns against writing that token in a comment again. There is no literal occurrence left in this file.

How it was tested

release.yml parses, and grep -c '\${{ *}}' is now 0. The step's own logic is unchanged apart from the removed commit — the tag-reuse branch and the push are the same lines, now reachable for the first time.

The honest limit: this is a release workflow, so the real proof is the next release. What that run should show, and what I will check, is a Push the release tag step that actually appears in the log with * [new tag] in it — rather than the interpolation error and silence it has printed every time so far.

installer#13 — the same comment bug had silently disabled the bundle CI's stale-component dispatch, plus the branch-protection fix for bundles.
The installer's own release.yml carries this identical bug and gets the same treatment before the edge → main cutover fires it for the first time.

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 *"Commit version bump and push tag"* step had two problems, and the first hid the second. ### It has never once executed An **empty template expression written literally in one of its comments** makes the runner fail to build the step's script — and a step it cannot build is **skipped without failing the job**: ``` Unable to interpolate expression 'format('…', steps.plan.outputs.version, steps.plan.outputs.tag, )': Failed to parse: unexpected token ")" ``` That is why `sidecar/Cargo.toml` still says `0.1.0` after six releases, and why the tag-reuse handling added in #27 was dead on arrival. The tags exist because **Gitea's release API creates one when it publishes** — this pipeline has been working by accident, and nobody could have noticed from a green run. ### And had it executed, it would have been declined `main` is protected: the pre-receive hook rejects the push. The installer's bundle job hit exactly that today, twice. A release must not depend on a write to a protected branch. ### So: the tag is the version Which is already how `servuo-plugins` works — that workflow was written this way on purpose ("*Tag only — no bump commit, so `main` is never pushed to*") and is the one release workflow in the org that has never needed a protection exception. Its tag pushes are proven against this same protection: ``` git push origin "${TAG}" * [new tag] v0.2.0 -> v0.2.0 ``` The workflow still writes the real version into `Cargo.toml` before building, so a **released binary self-reports correctly**; what it no longer does is commit that edit back. Nothing downstream reads the file — the next version is computed from the newest tag, and `CARGO_VERSION` is consulted only when no tag exists at all. The comment is reworded so the step can actually run, and warns against writing that token in a comment again. There is no literal occurrence left in this file. ## How it was tested `release.yml` parses, and `grep -c '\${{ *}}'` is now `0`. The step's own logic is unchanged apart from the removed commit — the tag-reuse branch and the push are the same lines, now reachable for the first time. The honest limit: this is a release workflow, so the real proof is the next release. What that run should show, and what I will check, is a `Push the release tag` step that actually appears in the log with `* [new tag]` in it — rather than the interpolation error and silence it has printed every time so far. ## Related - installer#13 — the same comment bug had silently disabled the bundle CI's stale-component dispatch, plus the branch-protection fix for bundles. - The installer's own `release.yml` carries this identical bug and gets the same treatment before the `edge → main` cutover fires it for the first time. ## 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:17:28 +00:00

fix(release): tag only, and stop pushing to main

PR Checks / rust-gates (pull_request) Successful in 1m0s

Details

36141a23df

The "Commit version bump and push tag" step had two problems, and the
first hid the second.

It has never once executed. An empty template expression written
literally in one of its comments makes the runner fail to build the
step's script, and a step it cannot build is skipped WITHOUT failing
the job. That is why sidecar/Cargo.toml still says 0.1.0 after six
releases, and why the tag-reuse handling added in #27 was dead on
arrival. The tags exist because Gitea's release API creates one when it
publishes -- the pipeline has been working by accident.

And had it executed, it would have been declined: main is protected, so
the push is rejected by the pre-receive hook. The installer's bundle job
hit exactly that today. A release must not depend on a write to a
protected branch.

So the tag is the version, as it already is in servuo-plugins, whose
release workflow was written this way on purpose and has never needed a
protection exception. The workflow still writes the real version into
Cargo.toml before building, so a released binary self-reports
correctly; what it no longer does is commit that edit back. Nothing
downstream reads the file -- the next version is computed from the
newest tag.

The comment is reworded so the step can actually run, and warns against
writing that token in a comment again. No literal occurrence is left in
this file.

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

PR Checks / rust-gates (pull_request) Successful in 1m0s

Details

This pull request can be merged automatically.

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:fix/release-tag-only

git checkout fix/release-tag-only

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/link#28