| name | frb-fix-main-ci |
| description | Use when flutter_rust_bridge CI fails on the default branch/main/master, especially to distinguish ordinary CI repair from a regression introduced after a previously green default-branch commit. |
FRB Fix Main CI
Use this when CI is failing on the default branch (main / master) or on a commit that is already part of the default-branch history.
Choose a Path
Default-branch CI failures usually have two possible repair paths. Choose based on the evidence in the latest relevant run.
Path A: Ordinary CI Repair
Use this path when the failure looks like a known FRB CI shape: flaky job, generated diff, lint drift, stale generated output, dependency-order failure, or downstream symptom already covered by existing CI triage.
Read frb-fix-ci and repair the failure directly:
- Check the latest relevant run, not stale status.
- Use
gh-actions-live-logs when reading GitHub Actions job logs.
- Classify flakes, generated diffs, lint drift, dependency-order failures, and propagated downstream symptoms before deep debugging.
- Prefer fixing prerequisite jobs such as
Generate, Integrate, or high-relevance Generate Internal before chasing later build/test symptoms.
Path B: Regression Investigation
Use this path when the failure is not obviously a known FRB CI maintenance issue, or when several default-branch commits/runs suggest something recently broke.
A default-branch failure is often a regression. There should usually be an older default-branch commit that passed the same CI path. Study what changed between the green baseline and the red commit, then fix the source of that regression.
Before writing a regression fix, answer these questions:
- What is the failing default-branch commit and workflow run?
- What is the nearest older default-branch commit with a green run for the same workflow or job family?
- Which commits or merged PRs sit between the green baseline and the red commit?
- Does the failure reproduce at the red commit but not at the green baseline, using the same
./frb_internal ... command and the FRB dev environment rules?
- Which source change most directly explains the regression?
Regression Workflow
- Capture the exact failing jobs and the first useful error from CI logs.
- Find the newest passing default-branch run for the same workflow/job family.
- Compare the commit range between green and red:
git log --oneline --decorate <green-sha>..<red-sha>
git diff --stat <green-sha>..<red-sha>
- If the range is broad or the culprit is unclear, bisect with the smallest meaningful reproduction command.
- Fix the source of the regression, not just the generated or downstream symptom.
- Add or adjust regression coverage when the bug is behavioral. For pure CI/tooling drift, document the before/after evidence in the PR.
What Not To Do
- Do not treat default-branch CI as "just rerun until green" unless logs strongly indicate infra flake.
- Do not force every default-branch failure through regression bisect when
frb-fix-ci already identifies a direct CI maintenance fix.
- Do not only repair checked-in generated files if the generator, template, version pin, or environment change is the real source.
- Do not chase downstream job failures while an upstream generation or integration job is still red.
- Do not assume the newest red commit is the sole cause without checking the nearest green baseline and intervening changes.
PR Expectations
For a PR that fixes default-branch CI, include:
- Failing commit SHA and workflow/job URL.
- Nearest green baseline SHA or run, if available.
- The reproduction command used locally or in Docker/Tart.
- The suspected or confirmed culprit commit/PR.
- Why the fix addresses the source of the regression.
Use frb-prepare-pr before opening the PR.
