ci: fail main when library code is merged but never released - #21
Merged
Conversation
Twice now a user-visible fix merged, VERSION stayed put, no tag was pushed, and go get kept serving the broken version: #9 (Solana paid GETs) merged -> VERSION stuck at 0.19.1 #17 (paid-GET caching) merged -> VERSION stuck at 0.19.3 Both PRs said "VERSION/CHANGELOG left for /ship" and /ship never ran. The Go module proxy only serves tags, so merged is not released — the repo looked fixed while every consumer stayed broken. Remembering has now failed twice; this makes the state visible instead. Two conditions fail the job: - VERSION bumped with no matching tag (a release started and abandoned) - non-test .go files changed since the latest tag (code users cannot get) Backtested against real history: passes on every release commit and on today's main, fails on both 942a267 and 26d2809 — the two commits where the miss actually happened. Test-only, docs, CI and config diffs are excluded; they ship nothing to consumers. PRs are not gated, since this repo's convention is that PRs leave VERSION alone. The job is expected to be red between merging library code and cutting the release. That red is the signal.
VickyXAI
pushed a commit
that referenced
this pull request
Aug 4, 2026
Ships the no-wallet guard hoist from #19 (closes #15). Also on main since 0.19.4, neither shipping library code: #20 corrects the README FAQ that told Solana users the Go SDK was Base-only, and #21 adds the release gate that flagged this very commit as missing. First release caught by that gate rather than by a human noticing the tag had fallen behind.
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.
Why
This has bitten twice, in the last hour, on the same repo:
0.19.10.19.3Both PRs said "VERSION/CHANGELOG intentionally untouched — left for
/ship"./shipnever ran. The Go module proxy only serves tags, so merged is not released: the repo looked fixed while every consumer stayed broken.The second miss was caught by a human noticing
v0.19.3was 4 commits behindmain. That is not a control.What it checks
On push to
main, two conditions fail the job:.gofiles changed since the latest tag — library code users cannotgo get.The error output names the unreleased files and lists the commits, so the fix is obvious from the log alone.
Backtested against real history
Not hypothetical — I ran the logic against actual commits in this repo:
origin/maintodayeee32bf942a26726d2809It catches exactly the two moments it was written for, and stays quiet otherwise.
Deliberately not gated
':(exclude)*_test.go'pathspec works: PR test(solana): pin zero client RPC on a paid GET with a server blockhash #18's test-only commit produces an empty file list.Expected to be red sometimes
Between merging library code and cutting the release, this job will be red. That red is the point: it is the repo saying users don't have this yet. It goes green when you release. The workflow comment says so, so nobody "fixes" it by deleting it.
Follows the commenting style of
brand-numbers.yml, which likewise explains why the check exists rather than just what it runs.bash -nclean.