ci: Fix Release Version Resolution for Untagged and Resumed Runs - #233
Conversation
The release workflow resolved its version in one inline shell block under `set -euo pipefail`, where two paths could not succeed. Filtering tags through `grep` made a no-match fatal. On the ordinary untagged tip of `main`, `git tag --points-at HEAD | grep -E '^v[0-9]+...'` exits 1, and the step died before reaching its skip handling or `next-release-version.sh`, so a deployable commit could not obtain a release version (#228). Selecting stable tags now reads exit 1 as an empty answer while exit 2 and above still fail the release, which also lets the missing-previous-tag case report its own error. The rerun-resume path then rejected the tag it had itself chosen. With a stable tag already pointing at `HEAD` and no release published, the version comes from that tag, and the following existence check failed merely because the ref existed (#229). It now compares the tag's commit against the release commit, so only a tag on some other commit is a collision; `Create tag` already tolerates a tag that exists. The block moved into `.github/scripts/resolve-release-version.sh`, beside the `next-release-version.sh` it calls, so `tests/release-version-resolution.sh` can cover every path: automatic, resumed, skipped, dispatched, pushed-tag, and the runs that must be refused, each against a throwaway repository with a stubbed `gh`.
|
Ready for review at That head carries the whole change: Two things worth a reviewer's attention:
The step's |
|
@codex review |
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. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fdf2cfc44e
ℹ️ 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".
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
Records the post-merge Release failure on 55840f3, upstream's LibreChat-AI#228/LibreChat-AI#229 fix in PR LibreChat-AI#233 (fd9a4fa, v1.2.0), the fork guard for the tagless fork, and the gated dispositions left open (merging PR #25, cutting an initial stable tag). Also adds PR #25 to the ledger's patch-index row.
Records the post-merge Release failure on 55840f3, upstream's LibreChat-AI#228/LibreChat-AI#229 fix in PR LibreChat-AI#233 (fd9a4fa, v1.2.0), the never-publish policy for the tagless fork, and the one remaining gate (merging PR #25).
Fixes #228
Fixes #229
The release workflow resolved its version in one inline shell block under
set -euo pipefail, where two paths could not succeed.#228 — untagged
mainaborted version resolution. Filtering tags throughgrepmade a no-match fatal. On the ordinary untagged tip ofmain,git tag --points-at HEAD | grep -E '^v[0-9]+...'exits 1, so the step died before reaching its skip handling ornext-release-version.sh, and a deployable commit could not obtain a release version. Selecting stable tags now reads exit 1 as an empty answer while exit 2 and above still fail the release. That also lets the missing-previous-tag case report its own error instead of aborting anonymously.#229 — a rerun could not resume publication. With a stable tag already pointing at
HEADand no release published, the version comes from that tag, and the following existence check then failed merely because the ref existed. It now compares the tag's commit against the release commit, so only a tag on some other commit is a collision.Create tagalready tolerated a tag that exists, so the rest of the recovery path was correct.Why it moved to a script. The block became
.github/scripts/resolve-release-version.sh, beside thenext-release-version.shit calls, because neither defect was reachable by a test while the logic lived in workflow YAML.tests/release-version-resolution.shnow covers every path against throwaway repositories with a stubbedgh: automatic release, resumed release after tag creation, an already-published tag, a calculated tag held by another commit, a stale CI run, documentation-only ranges, dispatch with and without thevprefix, release candidates, dispatch from a topic branch, an existing dispatched version, a malformed version, and a pushed older patch tag that must not becomelatest. The step'senvblock is unchanged, so the workflow's inputs and outputs are the same.docs/RELEASING.mdalready documents both behaviours ("a rerun also resumes publication if the tag was created before a later step failed"); this makes them true.Verification
tests/release-version-resolution.sh— 13 cases, passed.tests/release-versioning.sh— passed, untouched.release.ymlandci.ymlparse as YAML with steps and outputs intact;bash -nclean on both scripts.shellcheckandprettierare unavailable in my sandbox, and CI has no shellcheck lane.