fix(release): tag with the v prefix, and publish a GitHub release - #31
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 464700f262
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| VERSION="$(cat VERSION)" | ||
| # v-prefixed, matching every tag this repository and api-reference already carry. | ||
| # The version inside the package stays bare; only the git tag is prefixed. | ||
| VERSION="v$(cat VERSION)" |
There was a problem hiding this comment.
When this workflow first runs after the change, VERSION is still 1.0.0, while the parent commit records that 1.0.0 has already been published under the bare 1.0.0 tag. Looking up only v1.0.0 therefore misses the existing release, creates a second tag, and triggers release.yml; that job then attempts to push flat_api-1.0.0.gem again and fails before reaching the new gh release create step. As a result, merging this fix adds the unwanted duplicate tag but still does not create the GitHub release; the transition needs to recognize the legacy bare tag and create its release without republishing the gem.
Useful? React with 👍 / 👎.
Two things the release path got wrong, both visible on the repository page. The tag carried no prefix. Every tag in this repository, and every tag in api-reference, is v-prefixed, and the workflows introduced with the new pipeline created a bare one from the VERSION file. The tag list now mixes the two styles. tag-on-merge creates vX.Y.Z, release.yml triggers on it, and the assertion that the tag matches the packaged version compares against the tag with the v stripped, because the version inside the package never carries it. The four tags already published (2.0.0 and 2.0.1 here, 1.0.0 in the ruby and javascript clients) are left as they are: the registries record those versions and moving a published tag gains nothing. Nothing created a GitHub release, only a tag, so the Releases page still presented a version from 2018 as the latest one, which is what anyone browsing the repository sees first. release.yml now creates it, taking the notes from the CHANGELOG section for the version so the release says what changed. That needs contents: write, which the job did not have. A re-tag is a no-op now, not a failed release. npm error You cannot publish over the previously published versions: 1.0.0. Nothing was damaged: the published package is the same artifact and is still installable. But a red release on a version that is correctly out is the kind of failure people learn to ignore, and re-running a release, or changing the tag scheme as this just did, are both ordinary things to do. The publish step is skipped when the version is already in the registry, and the GitHub release step reports and moves on when the release exists rather than erroring on the create.
464700f to
430477f
Compare
1 participant
Two things the release path got wrong, both visible on the repository page.
The tag carried no
vEvery tag in this repository, and every tag in
api-reference, isv-prefixed. The workflows introduced with the new pipeline created a bare one fromVERSION, so the tag list now mixes both styles.tag-on-merge.ymlcreatesvX.Y.Z.release.ymltriggers on it, and the tag-matches-version assertion compares against the tag with thevstripped, because the version inside the package never carries it.The four tags already published (
2.0.0and2.0.1in python,1.0.0in ruby and javascript) are left alone: the registries record those versions and moving a published tag gains nothing. The CHANGELOG compare links point at whichever form actually exists.Nothing created a GitHub release
Only a tag, so the Releases page still presents a version from years ago as "Latest" — the first thing anyone browsing the repository sees.
release.ymlnow creates the release, taking its notes from the CHANGELOG section for that version. That needscontents: write, which the job did not have.Verified the note extraction against the real CHANGELOG: it returns the right section, and falls back to a pointer when a version has no entry.