ci(visual): stop running the visual baseline job on pull requests - #1755
Conversation
Owner decision, 2026-08-09: the pixel gate taxes exactly the work it exists to support. During a redesign the honest result is red on every UI pull request, and the baselines cannot be refreshed until a run has produced the new images, so that red is unavoidable rather than actionable. It was never merge-blocking -- `continue-on-error: true`, and absent from `pr-required`, whose needs list is [changes, static-pr, safety, coverage, build, container-images, ui-critical-fast, ui-critical, db-reset-verify]. But a red check nobody can act on mid-iteration is friction whether or not it gates, and it generated a steady stream of failure notifications on PR #1743 while the only correct response was "yes, that is the change". Drift is still caught. The job keeps running on pushes to main and release branches, on the weekly schedule, and on demand via workflow_dispatch. That moves the signal to where a refresh is cheap -- after the change has landed, against a run whose artifact already contains the new images -- instead of interrupting the change. One command refreshes it: npm run design-system:baselines:adopt -- --from <artifact> --run-id <id> --head <sha> --reviewed-by "<name>" --write Nothing else changes: the job, its targets, its provenance contract and its advisory status are untouched, and no required check is added or removed. Verified: npm run check:github-actions passed; ci-cache-safety 18 passed, 11 skipped; no test pins this job to pull_request; format clean. Refs #118
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 18 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe CI workflow now skips the ChangesVisual baseline CI
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/ci.yml:
- Line 685: Correct the owner-decision date in the workflow comment near the
“Deliberately NOT on pull_request” note to the actual completed decision date,
replacing the future-dated 2026-08-09 value with August 8, 2026.
🪄 Autofix
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: Pro
Run ID: 2c54baf4-4d54-4a35-9f7a-a9767136d051
📒 Files selected for processing (1)
.github/workflows/ci.yml
![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: ae53a8845d
ℹ️ 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".
|
@codex resolve actionable Codex review findings for this pull request and current head using the repository instructions. This is the pull request's single automatic repair pass: do not perform a fresh review, create new standalone findings, or request another review. Work only the existing unresolved Codex threads on the current head. The only repository destination is BigSimmo/Database, and the only branch destination is the pull request head branch claude/ds-visual-advisory-off-prs at starting commit be0d337; never publish fixes to a detached or synthetic work branch and never create a stacked pull request. Use the authenticated GitHub connector to commit each approved fix to BigSimmo/Database:claude/ds-visual-advisory-off-prs, then verify that the pull request head contains the published commit before reporting success. Always fix P0 and P1 findings. For P2 and lower findings, fix only clear, scoped, low-risk issues; otherwise disposition them with a concise reason. For a fixed thread, reply with as the first line and as the second line. For a no-code disposition, use followed by . These result markers authorize the workflow to close that exact thread only after it verifies a fixed commit is the pull request head; a local-only commit is not a fix. If publication or verification fails, do not use either result marker, do not claim success, and leave the thread open with the blocker. If human input or new authorization is required, do the same. Finish only after every actionable thread is fixed or dispositioned and closed, or explicitly left open for a human decision. Do not update the branch from main, address unrelated reviews, broaden scope, or create more than one scoped fix commit. Do not use external APIs, paid services, credentials, dependency changes, or broad refactors unless explicitly authorized. Add targeted tests where behavior changes and run the narrowest relevant validation. |
|
Codex Review: Didn't find any major issues. Nice work! 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". |
Allowlist push/schedule/workflow_dispatch so merge-queue UI churn does not re-run the advisory pixel gate, and document the schedule in testing.md.
Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
2 participants
Summary
visual-baselineon pull requests. It keeps running on pushes tomainandrelease/**, on the weekly schedule, and on demand viaworkflow_dispatch.Owner decision, 2026-08-09. The pixel gate taxes exactly the work it exists to support: during a redesign the honest result is red on every UI pull request, and the baselines cannot be refreshed until a run has produced the new images — so that red is unavoidable rather than actionable.
It was never merge-blocking. The job is
continue-on-error: trueand absent frompr-required, whose needs list is[changes, static-pr, safety, coverage, build, container-images, ui-critical-fast, ui-critical, db-reset-verify]. But a red check nobody can act on mid-iteration is friction whether or not it gates — it produced a steady stream of failure notifications on #1743 while the only correct response was "yes, that is the change".Drift is still caught, just later and cheaper. Moving the signal to post-merge puts it where a refresh costs one command against a run whose artifact already contains the new images:
Nothing else changes: the job, its six targets, its provenance contract and its advisory status are untouched, and no required check is added or removed. The in-code comment records that neither
pull_requestnorpr-requiredshould be re-added without the owner saying so — that promotion was step 3 of#118and is now explicitly off.Trade-off, stated plainly: a PR can now move a surface and land before anything notices, with the red appearing on the subsequent
mainpush instead. That is the intended exchange — the gate stops being a interruption and becomes a post-merge report. If you later want pre-merge coverage back without the noise, the narrower option is running it only on PRs carrying an opt-in label.Verification
npm run check:github-actions—GitHub Actions pin check passed.tests/ci-cache-safety.test.ts—18 passed | 11 skipped (29).pull_request.npm run formatclean.Risk and rollout
git revert, or delete thegithub.event_name != 'pull_request'clause.Refs #118.
Summary by CodeRabbit