fix(release): tag with the v prefix, and publish a GitHub release - #45
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: a0b47029f1
ℹ️ 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".
| TAG="${GITHUB_REF_NAME}" | ||
| # Every tag in this repository, and in api-reference, carries the v. The version | ||
| # inside the package never does, so the tag is compared with it stripped. | ||
| TAG="${GITHUB_REF_NAME#v}" |
There was a problem hiding this comment.
For any future version that has only the newly created vX.Y.Z tag, stripping v here makes the first Publish step invoke gh release create X.Y.Z --verify-tag; the gh release create documentation states that --verify-tag aborts when that exact tag does not exist. The workflow therefore fails after publishing to PyPI and never reaches the later step that correctly uses GITHUB_REF_NAME; for versions where a legacy bare tag does exist, it instead creates an unwanted release for that older tag. Keep the bare version only for changelog/package handling and use the prefixed ref for the single release-creation step.
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.
a0b4702 to
3badb95
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.