fix(versions): pin the trunk to published releases and fix released pin headers - #710
Open
Aleksei Sviridkin (lexfrei) wants to merge 2 commits into
Open
Aleksei Sviridkin (lexfrei) wants to merge 2 commits into
Aleksei Sviridkin (lexfrei) wants to merge 2 commits into
Conversation
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Aleksei Sviridkin (lexfrei)
force-pushed
the
fix/trunk-version-pins-refresh
branch
3 times, most recently
from
September 23, 2026 13:21
973f32f to
88c740b
Compare
update_versions.sh picked the default cozystack_tag from the upstream git tag list. A tag exists as soon as it is pushed, while its GitHub release can still be a draft with no assets, so the trunk could be pinned to a version whose releases/download URLs all return 404. Resolve the default from the GitHub releases API instead, keeping only published, non-draft, non-prerelease releases and taking the highest version rather than the newest one, since a patch of an older minor can be created after a newer minor. An explicit --cozystack-tag still wins. An optional GITHUB_TOKEN goes to curl on stdin rather than in argv, so it never shows up in a process listing. Without a tag the script needs jq and says so when it is missing, instead of reporting that upstream has no published release. CLAUDE.md and CONTRIBUTING.md now list jq as a required tool. hack/test_version_pins.sh is an offline self-check that feeds the resolver release-list fixtures and runs the script against a stub curl to check where the token goes and the missing-jq error. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
release_next.sh copied next.yaml into the new vX.Y.yaml verbatim, so a released pin file kept the trunk header saying 'make update-all' regenerates it to track upstream main. That is false for a released file, which update-all never touches. Rewrite the leading comment block and the trunk wording in the section comments when snapshotting, and correct v1.6.yaml, the one released file that carried the trunk header. The header does not repeat the pinned version: patch releases bump the values by hand, and a copy in the comment would go stale. Only comments change; no pinned value moves. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
Aleksei Sviridkin (lexfrei)
force-pushed
the
fix/trunk-version-pins-refresh
branch
from
September 23, 2026 13:26
88c740b to
78a34c4
Compare
Aleksei Sviridkin (lexfrei)
marked this pull request as ready for review
September 23, 2026 13:47
Aleksei Sviridkin (lexfrei)
requested review from
Andrei Kvapil (kvaps),
Timofei Larkin (lllamnyp),
myasnikovdaniil and
Timur Tukaev (tym83)
as code owners
September 23, 2026 13:47
This branch has not been deployed
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.
Two fixes in the pipeline behind
data/versions/*.yaml.A plain
make update-allcould pin the trunk to a release that does not exist yet. With no--cozystack-tag,hack/update_versions.shtook the newest upstream git tag, but a tag exists as soon as it is pushed, while its GitHub release can still be a draft with no assets. That is how the trunk once ended up on v1.5.3 with everyreleases/downloadURL returning 404. The default now comes from the GitHub releases API: the highest published, non-draft, non-prerelease release. It sorts by version rather than creation time, because a patch of an older minor can be published after a newer minor. An explicit--cozystack-tagstill wins. If the API request fails or finds nothing published, the script exits with an error and leaves the pin file untouched.make update-allwithout a tag now needsjq, so the required-tools lists inCLAUDE.mdandCONTRIBUTING.mdboth name it.hack/release_next.shcopiednext.yamlinto the newvX.Y.yamlverbatim, so released files kept the trunk header sayingmake update-allregenerates them. The snapshot now gets its own header, andv1.6.yaml, the only released file that had the trunk header, is corrected. Only comments change, no pinned value moves.hack/test_version_pins.shis an offline self-check. It feeds the resolver release lists with a draft, a prerelease, an older-minor patch created last and nothing published, and runsrelease_next.shin a sandbox to check the header and values. Against the live API the script produces exactly the committednext.yaml.hugo --gc --minifypasses.