Mobile CI Release Flow

Overview

Run a repeatable go/no-go workflow for Android and Flutter branches. Detect project stack, execute targeted verification, triage failures by root cause, and publish a release-readiness summary.

Workflow

1. Detect stack and pipeline

• Run scripts/ci_release_snapshot.sh <repo_root> first.
• Read detected CI files, Android modules, Flutter apps, and version markers before selecting commands.

2. Execute the minimal verification matrix

• For Android projects with gradlew, run from repo root: ./gradlew test lint assembleDebug.
• For Flutter projects with pubspec.yaml, run: flutter pub get, flutter analyze, flutter test.
• Add project-specific CI commands only when they already exist in pipeline config.

3. Triage failures with root-cause priority

• Classify failures as compile, test, lint, configuration/signing, dependency resolution, or infrastructure flake.
• Fix the earliest causal failure first; avoid fixing downstream noise first.
• Prefer the smallest safe patch; avoid architecture refactors during CI stabilization.

4. Evaluate release readiness

• Confirm version markers are updated where required (versionCode/versionName, pubspec.yaml version).
• Confirm release notes or CHANGELOG.md include user-visible changes and known risks.
• Confirm blocker-level crash risks are addressed for primary user flows.

5. Produce decision output

• Return one of: GO, GO WITH RISKS, NO-GO.
• Include blocker list, warning list, and explicit next actions.

Output Format

Use this exact section structure in the final response:

# CI + Release Readiness

## Decision
GO | GO WITH RISKS | NO-GO

## Blockers
- ...

## Warnings
- ...

## Evidence
- Commands executed:
- Key failing/passing targets:
- CI files reviewed:

## Release Notes Draft
- User-visible changes:
- Risk notes:

## Next Actions
1. ...
2. ...

Guardrails

• Preserve existing repository conventions and CI style.
• Do not remove tests to make CI green.
• Do not change signing/release keys unless explicitly requested.
• Flag flaky tests separately from deterministic failures.

References

• Use references/release-checklists.md for Android/Flutter release QA criteria.