feat(hack): generate docs from a pre-tag ref and fail loudly on fetch errors - #631
feat(hack): generate docs from a pre-tag ref and fail loudly on fetch errors#631myasnikovdaniil wants to merge 2 commits into
Conversation
… errors update-all could only fetch content from a ref named exactly like RELEASE_TAG (the Makefile overrides BRANCH with it), which forces docs generation to wait until the final tag exists. The new FETCH_REF variable (default: BRANCH, so every existing invocation is byte-identical) lets the release flow point content fetching at a staging branch, rc tag, or SHA while version routing still keys on RELEASE_TAG — enabling the docs PR to be prepared at promote time, before the stable tag is cut. update_apps.sh also rewrote destination docs before fetching and swallowed curl failures, so a bad ref or a raw.githubusercontent hiccup silently produced stub docs that could be committed and merged. Fetch now goes to a temp file first with curl --retry 3; any fetch failure or empty body aborts non-zero with the app and URL named, leaving existing docs byte-identical. A trap covers temp cleanup on the non-fetch error paths. Note the intended strictness: update-all against an older tag whose tree lacks a currently-listed app now fails the job instead of committing a stub for it. Assisted-By: GPT-5 <noreply@openai.com> Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reached
Next review available in: 13 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM — no blockers.
Fail-loud on fetch error verified across all branches: set -euo pipefail + curl -f + if ! ... wrapper + empty-$tmp guard, with pipefail propagating curl's exit through sed/awk. Happy-path output is byte-identical to before (only --retry 3 added), and template/notice writes now happen strictly after both guards, so a fetch failure can no longer publish an empty stub. All 6 call sites switched to
Non-blocking notes:
- hack/update_apps.sh:116 — the
[[ ! -s "$tmp" ]]guard treats a README that is a single H1/H2 line as failure (awk at :110 drops the first heading line → empty output → the whole docs job fails). Unrealistic for real app READMEs, but a behavioral edge distinct from the "empty body" case in the description. - hack/update_apps.sh:76 — shellcheck SC2034:
SRC_DIRunused (pre-existing). - No automated regression test for the fail-loud behavior; relies on the manual runs documented in the PR body (consistent with hack/ having no test harness).
2 participants
What this PR does
Today
make update-all RELEASE_TAG=vX.Y.Zcan fetch content only from a ref named exactly like the release tag: the Makefile pinsBRANCH := $(RELEASE_TAG), and every fetch goes toraw.githubusercontent.com/cozystack/cozystack/${BRANCH}/.... That forces docs generation to wait until the final tag exists — which is why the docs PR can only be opened after the release is already public. The upcoming promote-flow change in cozystack/cozystack wants to open this PR at promote time, before the stable tag is cut, generating from the digest-pinnedrelease-X.Y.Zstaging branch.Two changes:
Makefile: newFETCH_REF ?= $(BRANCH)— the ref content is fetched from. It defaults toBRANCH(which stays pinned toRELEASE_TAGwhen set), so every existing invocation, including the currenttags.yamlone, behaves byte-identically. PassingFETCH_REF=<staging-branch|rc-tag|sha>fetches content from that ref while version routing (DOC_VERSION,release-next,update-versionsgating) still keys onRELEASE_TAG. The sixupdate_apps.sh/update_versions.shinvocations now pass--branch "$(FETCH_REF)";show-targetechoes it.hack/update_apps.sh: fail loudly instead of stubbing. Previously the script rewrote the destination doc (template copy + autogenerated notice) before fetching, and a failed fetch only printed a warning and continued with exit 0 — so a bad ref or a transient raw.githubusercontent error produced stub docs indistinguishable from a real update, which could be committed and merged. Now the README is fetched into a temp file first (curl --retry 3, BOM strip and heading drop unchanged); any fetch failure or empty body exits non-zero naming the app and URL, leaving existing docs byte-identical. A trap cleans the temp file on non-fetch error paths too.Intended strictness worth acking in review:
make update-allagainst an older tag whose tree lacks a currently-listed app now fails the docs job instead of committing a stub for that app. That couples the app roster to the fetched ref, deliberately — a stub merged into version docs is worse than a red job.Deliberately out of scope: the manual
template-*targets (fill_templates.sh) keep using$(BRANCH)and their soft-fail behavior; they are not part of the automated release path.Verification
make show-targetin all modes: legacyBRANCH=... RELEASE_TAG=...resolvesFETCH_REFto the tag (byte-identical behavior),FETCH_REF=release-1.6.0-rc.4 RELEASE_TAG=v1.6.0keeps routing on the tag while fetching from the staging ref, plain no-var runs stay onmain. Live positive run:update_apps.sh --branch v1.6.0produces real (non-stub) docs for all apps. Live negative run:--branch this-ref-does-not-existexits 1 with the app and URL named and the destination tree byte-identical. Empty-body guard exercised.make update-all RELEASE_TAG=v1.6.0 FETCH_REF=v1.6.0passes end-to-end;bash -nclean.