ci(examples): run integration tests on all platforms for release PRs#1629
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds GitHub Actions coverage for Supabase-backed Flutter example integration tests across six platforms, a Dart runner for platform-specific execution, and narrower CRUD test teardown cleanup. ChangesExample integration CI
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant Supabase
participant CloudflareTunnel
participant FlutterRunner
participant GitHubArtifacts
GitHubActions->>Supabase: start backend
GitHubActions->>CloudflareTunnel: expose API endpoint
GitHubActions->>GitHubArtifacts: upload endpoint.json
FlutterRunner->>GitHubArtifacts: download endpoint.json
FlutterRunner->>Supabase: run example integration tests
FlutterRunner->>GitHubArtifacts: upload done-target marker
GitHubActions->>GitHubArtifacts: poll completion markers
GitHubActions->>Supabase: stop backend
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
## What Adds a repo-level `.coderabbit.yaml` that disables CodeRabbit's failing commit status: ```yaml reviews: commit_status: true fail_commit_status: false ``` ## Why Open PRs are currently showing a red `CodeRabbit` check with the reason **"Review rate limited"** (e.g. #1630, #1629, #1627), even though nothing is actually wrong with the change. A completed review shows `pass` (e.g. #1626). - `commit_status: true` keeps the useful passing check for completed reviews. - `fail_commit_status: false` stops CodeRabbit from setting a `failure` status when it can't review (which is what the rate-limit case triggers). Committing the config overrides CodeRabbit's cloud/org defaults. ## Note If a rate-limited PR still goes red after this lands, the rate-limit failure path ignores this flag and the only remaining lever is `commit_status: false` (disables the check entirely, losing the green pass too).
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/scripts/run_example_integration_tests.dart:
- Around line 127-144: Update the child-process wait in _run to enforce a finite
timeout around process.exitCode. When the timeout expires, terminate the process
before reporting the failure and exiting, while preserving the existing
nonzero-exit handling and exit-code propagation for processes that finish
normally.
- Around line 33-41: Change the failure handling in _run to throw an error
instead of calling exit(exitCode), allowing the try/finally around the example
loop to execute chromedriver?.kill(). Capture the failure at the top-level run
flow after cleanup and exit once with the appropriate nonzero code.
- Around line 26-31: Update the chromedriver startup flow in the web branch to
wait until the Process returned by Process.start has successfully bound port
4444 before continuing to flutter drive. Use the existing chromedriver process
handle to implement a readiness wait, and preserve the current behavior for
non-web targets.
🪄 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: Pro
Run ID: f1faa467-6d8b-4f36-a039-9c2b1aef9bd7
📒 Files selected for processing (2)
.github/scripts/run_example_integration_tests.dart.github/workflows/example-integration-tests.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/example-integration-tests.yml
Wait for chromedriver to bind port 4444 before running web tests, bound the child process wait with a timeout, and clean up chromedriver on failure by throwing instead of exiting inside _run.
What
Adds a workflow that runs every example's
integration_test/suite across all Flutter targets whenever a release PR is opened.pull_requestevents, gated to titles starting withchore(release)(the titlerelease-prepare.ymluses), so it only runs while a release is being prepared.web/, so each job scaffolds its target on the fly withflutter create --platforms=<target>rather than committing platform folders.backendjob on ubuntu hosts it and exposes the API gateway through a cloudflared quick tunnel. The platform jobs run concurrently, pull the endpoint from a run artifact, run their tests against it, then drop adone-<id>marker; the backend waits for all markers before stopping Supabase.Notes
tasks_test.dartteardown is scoped to only the titles the run created (inFilterinstead oflike 'E2E %') so the shared instance is safe under concurrent runs. The passkeys test already uses a unique email per run.TS_OAUTH_*secrets).minSdkVersion/ iOS deployment target than theflutter createdefaults; if a native build fails that's the likely cause.Summary by CodeRabbit
tasksrecords created/renamed by the current test run.