Repository navigation
CI: run the Firefox/Safari/phone tests alongside Chromium, and skip them on main when a draft run already passed the same tree - #3524
Conversation
…ktop Safari and Firefox four ways The release browser matrix waited for all three Production UI Chromium shards before starting, though it only reads the shared Playwright build. Main run 38352161182 had the build ready at minute 4.1 and the matrix idle until 15.2, ending at 34.1. On dispatch runs a single red Chromium shard skipped the whole matrix, so cross-browser failures surfaced only one full round later. The matrix now starts with Production UI. When UI changed it keeps its mockups-only Chromium path, since Production UI in the same run (or the merged PR's identical tree) proves production Chromium and still fails the run if red. Desktop WebKit (17.2/13.0/14.2 min) and Firefox (13.4/9.0/8.7) become the slowest legs once parallel, so both split four ways. No test is skipped. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qMDuRLipTaGrY6EyC89hm
|
Warning Review limit reachedYour organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Next included review available in 7 minutes. View limit details
Comment |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
🏁 CodeAnt Quality Gate ResultsCommit: ✅ Overall Status: PASSEDQuality Gate Details
|
Merging this PR will degrade performance by 59.58%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ |
medication-entities: medicationEntityMatchesInText |
4.7 ms | 11.6 ms | -59.58% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing claude/project-thread-fvnf7d (16bb3a0) with main (65860e7)
There was a problem hiding this comment.
BigSimmo has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Claude encountered an error after 2s —— View job I'll analyze this and get back to you. |
PR Summary by QodoRun cross-browser CI alongside Production UI
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Qodo FixerNo findings are available for this PR yet. Findings appear here once Qodo has reviewed the PR. |
Code Review by Qodo
No findings for this group No findings for this group 1. Skipped matrix's proving run is unlinked or mislabeled
|
CodeAnt Nitpicks1 code suggestion1. On a main push with
|
CodeAnt PR Risk: Medium Risk
Assessed commit: |
…ready passed the identical tree The Firefox/WebKit/iPhone matrix never runs on pull_request events, so main always re-ran it after every merge (about 20 to 30 minutes holding Railway's Wait for CI), even when the draft's full-suite dispatch run had just passed the byte-identical tree. The main tree proof now also looks for the newest green workflow_dispatch run of ci.yml on the merged PR head, recorded by its own Change scope as testing this exact tree within 24 hours, with every release-browser-matrix leg green. Only then does main skip the matrix. The schedule, release branches and dispatch runs never take this path. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014qMDuRLipTaGrY6EyC89hm
|
Code review by qodo was updated up to the latest commit 7af1daa |
|
On the "partial green matrix proves the whole matrix" finding (Qodo #1, CodeAnt risk note): not fixing, because no realistic path reaches it.
The two-leg self-test fixture exercises the classifier, not the workflow's leg count. Hard-coding 23 legs would add a second copy of the matrix to keep in sync, for no case the tree match doesn't already cover. Generated by Claude Code |
Code Review ✅ Approved🟡 Medium risk · Changes CI gating to skip the release browser matrix after dispatch-run tree proof; a proof-classification error could leave regressions undetected on main. Restructures CI so the Firefox, Safari and phone browser matrix starts once the shared Playwright build is ready, running in parallel with Production UI, and splits desktop WebKit and Firefox four ways. On main pushes, the matrix is skipped only when a green full-suite dispatch run on the same tree passed within 24 hours. No issues found. VerificationRules No rules evaluated Functional validation Not enabledAuto-approval Approved OptionsAuto-apply is off → Gitar will not commit updates to this branch. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Gitar |
|
CodSpeed "Performance Regression" on 16bb3a0 is not this PR's. This PR changes only CI config, CI scripts and their tests, and none of the benchmarked code ( Generated by Claude Code |
User description
Requested by Josh · project thread
Summary
Before: the Firefox, Safari and phone browser tests (
release-browser-matrix) waited for all three Chromium Production UI shards to finish before starting, although they only need the shared Playwright build. If any Chromium shard failed, the whole cross-browser matrix was skipped. And after every merge, main re-ran the whole matrix, even when the draft's full-suite run had just passed the identical tree.After: the matrix starts as soon as the shared build is ready, in parallel with Production UI. Desktop Safari (WebKit) and Firefox split four ways instead of three. On a push to main, the matrix is skipped only when a green full-suite
workflow_dispatchrun on the merged PR head recorded testing the byte-identical tree within 24 hours, with every matrix leg green. Every test still runs somewhere, one worker, zero retries, same timeouts.Measured (job timings read from GitHub):
How:
ui-criticalfrom the matrix'sneeds/if. The Chromium leg's mockups-only path keys onui_changed, because production Chromium is then proven by Production UI in the same run or by the merged PR's identical tree.scripts/ci-main-tree-proof.mjsgains amatrixgroup, proved only by a dispatch run under the same checks as the existing proof (same repo, same head, its own tested-tree record withevent=workflow_dispatchequal to tree(HEAD), fresh, every leg green). The job'sifaddstree_proven_matrix != 'true'inside its main-push clause only, so schedule, release branches and dispatch runs are unchanged.Areas touched: Delivery and assurance
Verification
node scripts/ci-main-tree-proof.mjs --self-test:ci-main-tree-proof self-test passed.(new cases: red leg, missing legs, other tree, wrong event record, red or stale dispatch run, tree mismatch, dispatch events never skip their own matrix)ci.ymlor the proof script:690 passed, 2 failures intests/test-runner-safety.test.ts(heavyweight lock) that fail identically on unmodified main in this container.Risk and rollout
Notes
Not done: refresh the release shard timing tables (they under-predict WebKit by about 25%). That needs the
release-ui-timingsartifacts, which this container cannot download.🤖 Generated with Claude Code
https://claude.ai/code/session_014qMDuRLipTaGrY6EyC89hm
CodeAnt-AI Description
Run cross-browser tests sooner and skip verified repeats on main
What Changed
Impact
✅ Earlier Firefox and Safari test results✅ Cross-browser failures reported with Chromium failures✅ Shorter main-branch CI after a verified full-suite run💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.