Verify what one tag produces, and what upgrading from v0.1.1 costs - #248
Merged
Merged
Conversation
Running v0.1.1 and this build side by side leaves an HTTP client one observable difference: a 405 now carries the JSON error body every other error already had. Status codes and bodies for PUT, GET, DELETE, and /healthz are identical, the proto has not been touched, and the v0.1.1 README's library example compiles against this package unchanged. v0.1.1 had no --data-dir, so an upgrade has no data to migrate at all. The release page says all of that, and says what it does not: an upgraded server opens a RESP listener on loopback that was not there before. A data directory this build cannot read is the one refusal an upgrade can hit, and the sentence it prints is the instruction. The datadir package tested the refusal; nothing tested that it reaches whoever ran the command, which is where it is read. Now something does. Rehearsing the tag locally found the rest. Five changelog fragments carried no issue number and rendered as dead links. Four described changes nobody outside this repository could observe, among them a Homebrew formula dropped and restored between the same two tags, which would have gone out as a release note saying both. `goreleaser check` failed on the deprecated brews section: the release job floats on ~> v2, so that was a working release path with an expiry date on it. Homebrew gets a cask now, and because nothing signs these binaries the cask strips the quarantine attribute, or the first run dies on a dialog instead of an error. Retiring the old formula is the tap's job and has an order to it: the cask does not exist until the release job pushes it, and tap_migrations.json is only read when a name resolves to nothing. Both tap changes therefore belong after the release, in one commit, which the release page now spells out rather than leaving to whoever does it next. Those instructions lived in two files that had drifted apart. One is enough.
github-actions
Bot
added
documentation
They were written before the number existed and guessed at it.
![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: 725e6b139d
ℹ️ 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".
`changie batch` writes the version file with no trailing newline and `changie merge` concatenates verbatim, so v0.1.1's heading landed on the end of the last v1 bullet and stopped being a heading at all — the release vanished from the changelog as a section. The end-of-file hook fixed the file afterwards, which was too late for the merge that had already run. Merging again fixes it, and the release page now names the symptom next to the other two worth looking for in a batch. The archive row multiplied three operating systems by four architectures and claimed the nine that come out. There is no darwin/386 and no windows/armv7; the row now lists what each platform actually gets.
Owner
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. 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". |
8 tasks
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.
Summary
Proves the two claims a v1 tag makes about its own release: that upgrading from v0.1.1 works as documented, and that one tag push produces every artifact. Almost no new code — the work was running both paths and correcting what they contradicted.
Type of Change
Changes
Upgrade path, measured. v0.1.1 and this build were run side by side over the same eight HTTP calls. One difference: a
405now carries the JSON error body every other error already had.PUT,GET,DELETE,/healthzand their 404s are byte-identical,api/kvsv1/kvs.protois untouched since v0.1.1, and the v0.1.1 README's library example compiles and runs against this package unmodified. v0.1.1 had no--data-dir, so there is no data to migrate. One thing does change and is now written down: an upgraded server opens a RESP listener on127.0.0.1:6379that was not there before, logged and skipped if the port is taken.TestServeRefusesADataDirItCannotRead. The one refusal an upgrade can hit.internal/datadirtested the refusal itself; nothing tested that it reaches whoever ran the command, which is where the sentence is actually read.Changelog, before it became permanent. Five fragments had no
Issueand rendered as[#<no value>]dead links — all five traced to #236. Four described changes nobody outside this repository could observe, including a Homebrew formula dropped in #228 and restored in #233, which would have shipped as one release note saying both.changes/v1.0.0.mdis batched and merged: 17 entries, no dead links.brews:→homebrew_casks:.goreleaser checkwas failing on the deprecated section, and the release job floats on~> v2— a working release path with an expiry date. Nothing signs these binaries, so the cask strips the quarantine attribute inpostflight, or the first run dies on a Gatekeeper dialog instead of an error. Retiring the old formula is the tap's job and has an order to it (the cask does not exist until the release job pushes it;tap_migrations.jsonis only read when a name resolves to nothing), so the release page spells out that both tap changes happen together, after the release.One release document.
docs/RELEASE.mdandcontent/docs/release.mdhad drifted apart; only the second is rendered and linked. Merged into it, with the pre-tag checks, what the nine archives and four container tags actually are, and why there are no release-candidate tags (latest-alpinewould move to one).Also cleaned up outside the tree: a stale
v0.1.2draft release, and theGH_PATsecret that #233 retired but left behind (no workflow references it).Testing
make allpassesAlso run:
goreleaser check(now passes),goreleaser release --snapshot --clean --skip=docker(nine archives,CHECKSUMS, cask generated with the rightbinaryandpostflight),hugo --minify. Docker was skipped locally for want of a daemon; the same command runs in thegoreleaserjob incd.ymlon this PR.Related Issues
None — no tracking issue.