Repository navigation
#148 — dual-link sticky comment + per-PR Pages preview (dogfood delivery) - #149
Conversation
Add an "Open ↗" GitHub Pages link beside the existing Download for each of the 4 PR-preview reports (jaffle-shop, playground, diff-showcase + dbt-project), by publishing each PR's reports to gh-pages/pr-<N>/<slug>/report.html. Reviewers open a report in one click from the PR instead of download → unzip → open. Dogfoods the per-PR Pages delivery the consumer recipe already prescribes. - mdbook.yml: deploy the book to the gh-pages branch root via peaceiris (keep_files: true). Pages now serves from the gh-pages branch so per-PR previews coexist with the docs at root (a deliberate move off the single-site Actions deploy — see #148 / the impl plan). - report-preview.yml: new publish-previews job (one job → one gh-pages push, no race; peaceiris → pr-<N>/) + a fork-aware dual-link sticky comment (Open ↗ / Download; the Open cell renders "N/A (fork)" on fork PRs whose read-only token can't publish). - pr-preview-cleanup.yml (new): remove gh-pages/pr-<N>/ on PR close. - recipe §8: sync the consumer cleanup snippet to the same shape. A shared `gh-pages` concurrency group (cancel-in-progress: false) across all three gh-pages-pushing jobs serializes peaceiris pushes so they don't race + lose commits. Delivery-only: no Rust / template / fixture change. Closes #148 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two pre-push review fixes (advisor): - publish-previews: add actions/checkout — peaceiris runs git against the repo to push gh-pages, so it needs a workspace with .git (the cleanup job + the consumer recipe both check out first; this job didn't). - mdbook.yml: keep the job name `mdbook (book build)` verbatim — it is a REQUIRED status check on main (branch protection). Renaming it would stall every future PR on a context that never reports. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 42 minutes and 6 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ 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 |
|
Ready to review this PR? Stage has broken it down into 4 individual chapters for you:
Chapters generated by Stage for commit 4c57096 on Jun 8, 2026 12:41am UTC. |
There was a problem hiding this comment.
Code Review
This pull request updates the GitHub Actions workflow recipe for PR review cleanup by restricting global permissions, adding concurrency control, skipping fork PRs, and passing the PR number via an environment variable. The review feedback suggests a cleaner way to conditionally commit and push changes only when there are staged files, avoiding the use of || exit 0 on git commit which could mask other failures.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
📄 Rendered report previewAll golden examples regenerated cleanly. 🟡 Golden examplesCommitted to
🐶 Live dogfood previewThis PR doesn't touch ▶ Open ↗ opens the report in your browser in one click — The Pages preview may take ~1 min to update after this comment Alternative: GitHub CLI# gh CLI >= 2.63 extracts into ./report-preview-playground/.
gh run download 27109781500 -R breezy-bays-labs/cute-dbt -n report-preview-playground
open report-preview-playground/playground-report.htmlPosted by |
What & why
Our own
report-preview.ymlsticky comment was download-only (login → download → unzip → open) — the exact friction epic #78 set out to kill, and our CI wasn't eating the per-PR-Pages recipe we already ship to consumers. This adds a one-click ▶ Open ↗ GitHub Pages link beside ⬇ Download for each of the 4 PR-preview reports, by publishing each PR's reports togh-pages/pr-<N>/<slug>/report.html.Delivery layer of Shape E (epic #78). The Phase-2 consumer Action (#120) is sequencing-blocked on v0.1.0 publish (#112/#74); this dogfood path is not blocked and de-risks the per-PR-Pages mechanics on us first.
Closes #148
Changes (delivery-only — zero Rust / template / fixture change)
mdbook.yml— deploy the book to thegh-pagesbranch root viapeaceiris/actions-gh-pages(keep_files: true). Pages now serves from thegh-pagesbranch so per-PR previews coexist with the docs at root. The job namemdbook (book build)is kept verbatim (it's a required status check). This is a deliberate move off the single-site Actionsdeploy-pages— branch-based push is far simpler for granular multi-directory deploys.report-preview.yml— newpublish-previewsjob (one job → one gh-pages push, no race;peaceiris→pr-<N>/<slug>/) + a fork-aware dual-link sticky comment. On fork PRs (read-only token can't publish) the Open cell renders🚫 N/A (fork)instead of a dead 404.pr-preview-cleanup.yml(new) — removesgh-pages/pr-<N>/on PR close.--ignore-unmatch,|| exit 0, fork gate).A shared
gh-pagesconcurrency group (cancel-in-progress: false) across all three gh-pages-pushing jobs serializespeaceirispushes so they don't race + lose commits.Pre-merge: production Pages already migrated
The Pages source was flipped to the
gh-pagesbranch out-of-band (book bootstrapped + verified serving 200 from the branch) so this PR's own run can validate the Open links end-to-end.mainstill carries the oldmdbook.ymluntil this merges — so a stray push tomainbefore merge would run the old Actions-source deploy against a branch-sourced Pages site (could revert the migration). Recommendation: merge promptly after review, ahead of any othermainpush. Rollback if needed: flip the Pages source back tobuild_type=workflow.Verification
actionlint+shellcheckclean on all 3 workflows; the dual-link jq simulated for both non-fork (Open ↗ links) and fork (N/A (fork)) + the empty case; the publisharrangeloop maps all 4 hyphenated slugs →pr-<N>/<slug>/report.html;mdbook buildclean.publish-previewsgreen → the 3 🟡 golden Open ↗ links serve 200 from…github.io/cute-dbt/pr-<this-PR>/…(after ~1 min Pages build). dbt-project won't light up (this is a delivery-only PR that doesn't touchdbt-project/) — its row shows the "doesn't touch" message, as expected.Notes
ci:prefix (notfeat:) — zero crate code changed, so no version bump (and release-plz is fix: release-plz fails to open release PR (GitHub App token 404) — blocks first publish #112-broken regardless).pr-<N>/won't auto-clean on close (the cleanup workflow isn't onmainuntil this merges) — harmless; can hand-remove later.DO NOT MERGE — Christopher's call.
🤖 Generated with Claude Code