ci(e2e): daily production read-only canary workflow#3191
Conversation
Production has no scheduled E2E: the prod deploy workflow runs no post-deploy packs, and backend releases, data issues or third-party changes can break the user experience without any frontend deploy at all (see the 2026-07-07 wave-crash incident). Add a daily cron that runs the manifest-resolved production canary packs (10 read-only packs, desktop chromium) via scripts/e2e-packs.cjs against 6529.io, with artifact upload and a Discord alert on scheduled failure. Read-only is enforced by the readonly mutation guard at the network layer; no secrets are needed because production is public. Merge order: requires #3190 (pack manifest + runner) on main first. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Punk 6529 <108035228+punk6529@users.noreply.github.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 8 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 Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
6529bot WCAG 2.2 AA analysis - 2ca2057Verdict: No WCAG findings This PR adds a CI-only GitHub Actions workflow ( |
6529bot general PR review - 2ca2057Verdict: Good to merge This is a well-constructed CI workflow: pinned action SHAs, minimal Nice-to-have
No blocking or correctness issues found in the diff. Note the workflow's real behavior depends on unmerged code in #3190, which is outside this diff's scope and could not be verified here. |
6529bot i18n analysis - 2ca2057Verdict: No i18n findings This PR adds a single CI-only GitHub Actions workflow ( The only strings present (workflow/job/step names and the Discord failure title/description at lines 89–90) are CI operator-facing notifications, not app UI, so the i18n message-structure and formatting-helper requirements do not apply. Note: coverage is scoped to the single changed workflow file; no localizable frontend surfaces were touched. |
6529bot crypto security analysis - 2ca2057Verdict: No security findings This PR adds a single CI-only GitHub Actions workflow ( From a crypto-security lens the workflow is sound:
No signature, nonce, chain-id, address-normalization, session, or transaction logic is touched, so the crypto/web3 review focus does not apply to this diff. Note: coverage is limited to the single changed workflow file; the referenced runner/manifest code in #3190 is not part of this diff and was not reviewed. |
|
6529bot GLM Swarm ReviewVerdict: Advisory only This GLM swarm is advisory and complements, not replaces, existing tests and existing reviewbots. Important
Nice-to-have
Testing feedback loop
Partial reviewer outputOne or more internal advisory reviewer slices were unavailable; the synthesis used the remaining reviewer output.
|
6529bot responsiveness review - 2ca2057Verdict: Responsive checks passed Root Cause / Summary All 32 checks passed with 0 failures across Blocking Findings None. No deterministic failures, no blank/near-uniform evidence unexplained, no missing native shell contract, no Electron branch failure, and no Next.js boot/overlay errors. Non-Blocking Findings
Platform Coverage
Screenshot evidence: native-mobile /the-memes, native-mobile /rememes, native-mobile /, native-mobile /meme-lab, native-mobile /discover, native-mobile /waves, native-mobile /meme-calendar, web-desktop /meme-lab, web-desktop /rememes, web-desktop /meme-calendar, web-mobile /meme-lab, electron-desktop /rememes and 19 more in the details. Deterministic responsiveness detailsVerdict: Responsive checks passed
Responsiveness runner summary6529bot Responsiveness SummaryStatus: pass Platform Context
Platform Matrix
Warnings
Slowest Checks
|



Issue
Production has no scheduled E2E of any kind: the prod deploy workflow runs no post-deploy packs, and the experience can break for users with zero frontend deploys involved — backend releases, data issues, third-party SDK changes (see the 2026-07-07 wave-crash incident, where prod broke and no staging-E2E-style gate existed on the prod path). PR 3 of the E2E architecture campaign.
Fix
A daily cron workflow that answers one question: is production working for users right now, whoever's fault?
Changes
.github/workflows/prod-canary.yml— daily at 05:30 UTC (offset from the 04:00 Device Farm crons so failures arrive as distinct signals) +workflow_dispatch./bin/6529 run e2e:packs -- --env production --trigger cron→ resolves the 10 read-only production packs fromtests/packs.manifest.ts(desktop chromium,workers=1), per-pack step-summary rowsValidation
30 5 * * *--env production --trigger cron --list→ exactly the 10 canary packs, manifest orderRisk
Low. New workflow only; touches no existing paths. Merge order: requires #3190 (manifest + runner) on main first — until then the cron would fail loudly on the missing script (fail-loud, not false-green).
Review Notes
🤖 Generated with Claude Code