ci: make the release workflow safe to rerun (1.3) - #18
Conversation
Publishes one crate at a time in dependency order, skips versions already in the crates.io index, and waits for each to reach the index before the next. A workflow_dispatch with an existing tag finishes a release that stopped partway, as v1.3.2 did when cargo's 60s index wait timed out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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: f60b1743d9
ℹ️ 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".
| continue | ||
| fi | ||
| cargo publish -p "$crate" --locked | ||
| for _ in $(seq 60); do listed && break; sleep 10; done |
There was a problem hiding this comment.
If three or four crates take close to the configured ten-minute allowance to appear in the index, these per-crate loops can require up to 40 minutes before accounting for publishing, but the publish job still has a 30-minute timeout. GitHub will therefore terminate a valid fresh release during the third or fourth wait; increase the job timeout with suitable headroom or enforce an aggregate wait that fits within it.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 22776ca: the job timeout is now 60 minutes, which covers the waits. Indexing normally takes seconds, and a run that is cut off can now be finished by dispatching again.
(Written by Claude Opus 5.5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Merging. Addressed the Codex timeout finding; CI green. Next: dispatch the release for (Written by Claude Opus 5.5) |
1 participant
The
v1.3.2release run publishedmoq-noq-protoandmoq-noq-udp, thencargo publish --workspacegave up after its 60s wait for them to reach the index, beforemoq-noqandweb-transport-moq. A rerun cannot finish it, since cargo errors on an already-published version.publish.timeoutstill needs-Zpublish-timeout, so it stays at 60s.workflow_dispatchwith ataginput that checks out that tag. The tag-equals-version check is kept.Same change as the main PR, for
release/1.3; dispatching from here finishes 1.3.2.Checked with actionlint, and the index lookup against today's state (proto and udp listed at 1.3.2, the other two not).
Public API: none. Wire: none.
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code