ci(release): wait for the tagged commit's CI instead of reading it as failed - #120
Merged
Merged
Conversation
… failed The publish gate required a `ci.yml` run on the tagged commit with conclusion `success`. A run that is still going reports `pending`, and the check treated that exactly like a failure -- so a tag pushed shortly after its merge, with CI still queued behind this run's own build jobs, was rejected for having "no successful ci.yml run". v0.1.2 hit this on its first attempt, on a commit that was green half an hour later and published unchanged on a rerun. Nothing was published in the meantime, so the gate did its job. Its verdict was still wrong, and the distinction it missed is the one that matters: not decided yet is not decided against. The step now polls until the run settles, bounded to 45 minutes, and says what it is waiting on. The red check runs on every iteration, so a run that turns red while we wait is caught too. Anything genuinely failing still exits on the spot -- only the undecided case waits. `timeout-minutes` on the job moves from 10 to 60 so it outlives that wait. Written and linted, not run: `release.yml` executes only on a pushed `v*` tag, so the next release is the first time this path is exercised.
The rewritten gate step lost its literal escapes: `printf '%s\n'` became a printf with a real newline inside the single quotes, and `awk -F'\t'` a real tab. That ends the YAML scalar mid-string, so actionlint refused the file outright -- `could not parse as YAML: could not find expected ':'` -- before it ever got to the shell. Caught by actionlint on the pull request, which is where a workflow edit is supposed to be caught: `bash -n` reads the extracted step and is happy with a literal newline, and shellcheck is not installed here, so nothing local would have seen it either.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
kingchenc
added a commit
that referenced
this pull request
Sep 2, 2026
Cuts 0.1.3 across the twenty version-bearing files this repository writes itself, and closes the changelog gap the previous release left open. ## Changelog `[Unreleased]` became `[0.1.3]`. One entry was missing from it and is added here: the `wickra-core` lockfile refresh from #122. The two entries already there -- the benchmarks pom that tracked a version deleted two releases ago (#121) and the publish gate that read a pending CI run as a failed one (#120) -- carry over unchanged. Everything merged since v0.1.2 is now described. `git log v0.1.2..main` lists exactly those three commits. ## Bump Run through `bump_version.py`, which reports 21 declarations rewritten: the workspace `Cargo.toml`, `Cargo.lock` via a real `cargo build`, the Python, Node (package, six platform stubs, lockfile, and the napi loader's version literal), Java, C# and R manifests, both poms that resolve the binding, `CITATION.cff` including its release date, and `SECURITY.md`'s supported-version table. `scripts/check_version_sync.py` agrees on all 21. The benchmarks pom is among them for the first time -- it was added to that check in #121, which is why this bump moves it rather than leaving it behind as 0.1.1 and 0.1.2 did. A grep for `0.1.2` outside the changelog returns one hit, `iana-time-zone-haiku`, whose own version happens to be the same string. ## Verification - `cargo fmt --all` -- no changes - `cargo test --workspace --all-features` -- all suites pass - `cargo clippy --workspace --all-targets --all-features -- -D warnings` -- clean
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The publish gate required a
ci.ymlrun on the tagged commit with conclusionsuccess. A run that is still going reportspending, and the check treatedthat exactly like a failure -- so a tag pushed shortly after its merge, with CI
still queued behind this run's own build jobs, was rejected for having "no
successful ci.yml run". v0.1.2 hit this on its first attempt, on a commit that
was green half an hour later and published unchanged on a rerun.
Nothing was published in the meantime, so the gate did its job. Its verdict was
still wrong, and the distinction it missed is the one that matters: not decided
yet is not decided against. The step now polls until the run settles, bounded to
45 minutes, and says what it is waiting on. The red check runs on every
iteration, so a run that turns red while we wait is caught too. Anything
genuinely failing still exits on the spot -- only the undecided case waits.
timeout-minuteson the job moves from 10 to 60 so it outlives that wait.Written and linted, not run:
release.ymlexecutes only on a pushedv*tag,so the next release is the first time this path is exercised.