ci: publish per-tag web client and seed /client/stable/#556
Conversation
Add a tag trigger to docs.yaml so v* pushes deploy the web client to /client/<tag>/, and (re)point /client/stable/ at the highest v* tag. A new promote-stable-client.yaml workflow re-resolves /client/stable/ on tag deletion (rollback path) and manual dispatch. The root /client/ redirect is intentionally left at ./main/ — flipping it to ./stable/ is a one-line follow-up once 1.2.x is tagged, so users hitting /client/ don't regress to a 1.1.x build that's missing fixes. Release-branch deploys no longer rewrite the root redirect; only main owns it. The redirect is self-healed on the next main push, and the new promote workflow keeps /client/stable/ in sync independently. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR adds version-aware documentation deployment to GitHub Pages. The main workflow now detects tag pushes matching Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/docs.yaml:
- Around line 25-26: The workflow's tag filter must match the publish trigger to
avoid selecting non-semver tags (e.g., v2-dev) for client/stable; update the
tags pattern here to the stricter semver regex used by the publish step (the
same 'v[1-9]*.[0-9]*.[0-9]*' / semver pattern) or add an explicit semver
validation before computing stable_slug so stable_slug only points to tags that
were actually published; modify the YAML tags entry or the stable_slug selection
logic (where stable_slug is computed) to enforce the same semver constraint.
- Around line 189-193: Update the checkout step to pin actions/checkout to a
full commit SHA and add persist-credentials: false (change the step using
actions/checkout@v6 to the exact commit SHA and include persist-credentials:
false) so the step doesn't leak write credentials; also make the tag selector
used with git ls-remote (the command that currently uses 'v[1-9]*') match the
workflow trigger regex (v[1-9]*\.[0-9]*\.[0-9]*) so stable tag resolution only
considers tags the workflow deploys (adjust the git ls-remote pattern to
'v[1-9]*\.[0-9]*\.[0-9]*').
In @.github/workflows/promote-stable-client.yaml:
- Line 67: The workflow currently uses the mutable tag "uses:
peaceiris/actions-gh-pages@v4"; replace each occurrence of that string with the
same action pinned to the full commit SHA (e.g. "uses:
peaceiris/actions-gh-pages@<full-commit-sha>") by looking up the canonical
commit for v4 in the peaceiris/actions-gh-pages repository and substituting the
tag with the immutable SHA in all workflows that reference it.
- Around line 31-33: Pin the workflow actions to immutable commit SHAs and
disable credential persistence: replace the floating action references
(actions/checkout@v6 and peaceiris/actions-gh-pages@v4) with their corresponding
commit SHAs, and add persist-credentials: false under the actions/checkout step
to avoid leaving the GITHUB_TOKEN available to subsequent steps; update the
peaceiris/actions-gh-pages reference to the specific commit SHA as well so both
actions are fixed to exact commits.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: ce90c6b6-04d9-4826-addc-1ea5dfee213e
📒 Files selected for processing (2)
.github/workflows/docs.yaml.github/workflows/promote-stable-client.yaml
The trigger filters 'v[1-9]*.[0-9]*.[0-9]*' but the ls-remote lookup used 'v[1-9]*', which would match non-semver tags (e.g. v2-dev) that weren't actually deployed and could rank above real releases under sort -V. Tighten both lookups to the trigger's glob so stable only points at tags the workflow publishes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
v[1-9]*.[0-9]*.[0-9]*) todocs.yamlso each release tag publishes the web client to/client/<tag>/(e.g./client/v1.1.5/), alongside the existing/client/main/and/client/release-x.y.z/paths./client/stable/at the highestv*tag — backports to older lines won't drag stable backward.promote-stable-client.yamlworkflow re-resolves/client/stable/on tag deletion (rollback path) and on manualworkflow_dispatch. Tag creation is handled bydocs.yaml./client/index.html; onlymainowns it. Self-heals on the next main push.Held for follow-up
The root
/client/redirect is intentionally left at→ ./main/for now. Users onmainare pulling 1.2.x fixes that aren't yet in tagged 1.1.x; flipping the root to./stable/today would regress them. Once v1.2.0 is tagged, the flip is a one-line PR (change themeta http-equivvalue in the heredoc).Resulting layout
/client//client/main/(flip →./stable/in follow-up)/client/stable//client/<highest v*>/(new)/client/v1.1.5/,/client/v1.0.193/…/client/main/main(unchanged)/client/release-1.3.x/Test plan
v0.0.1-testtag against a sandbox repo / fork: confirmclient/v0.0.1-test/lands andclient/stable/redirects to whichever real tag winssort -uV | tail.promote-stable-client.yamlfires andclient/stable/rewrites back.main: confirmclient/main/updates andclient/index.htmlstill redirects to./main/(no premature flip).release/1.3.x(or wait for next sync): confirmclient/release-1.3.x/updates andclient/index.htmlis not touched.workflow_dispatchofpromote-stable-client.yaml: confirm it resolves and pushes without errors.🤖 Generated with Claude Code
Summary by CodeRabbit