Reverts the tracking-issue job from 601088b: a single maintainer watching
the Actions tab doesn't need a bot filing issues at them, and GitHub
already emails on scheduled workflow failure.
Also moves the heartbeat from weekly to monthly. Nothing it watches --
cert expiry, secret rotation, dependency drift -- moves on a weekly
timescale, and a dispatch run before cutting a release is the check that
actually matters.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fastlane warns on every run that it will soon require Ruby 3.3.0 or
newer; both release workflows pinned 3.2. Bumping now means that break
lands on a quiet commit instead of mid-release. fastlane 2.234 already
supports 3.3 and no gem in either lockfile is version-sensitive, so this
stands alone — the lockfiles are unchanged.
Also gives the weekly dry-run somewhere to report. It broke on the
release after 5.1.0 and stayed red for weeks without surfacing, which is
the failure mode of any heartbeat nobody reads: it looks green by
default. Scheduled failures now open a tracking issue, or comment on the
existing one for each week it stays red. Dispatched runs are excluded —
those are already in front of whoever started them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Play rejects a version code it has already seen, and between releases
pubspec's code is by definition already published — so every scheduled
dry-run died on "Version code 69 has already been used" before reaching
any of the credential, signing, or store validation it exists to check.
It has been failing on that since 5.1.0 shipped.
Overrides the build number with epoch seconds, which is always unused and
always increasing. The bundle is validate_only, never published, so the
value is discarded. Only downside is the dry-run can no longer catch a
forgotten version bump, which the real release catches anyway.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- add `flutter: 3.44.2` to environment so `flutter pub get` fails locally
the moment the SDK drifts (was already drifting: local 3.44.2 vs the
3.44.1 pinned in CI)
- point all 8 workflow pins at `flutter-version-file: pubspec.yaml` so CI
reads the same field; bumping Flutter is now a one-line pubspec edit
instead of editing 5 workflow files
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
run build_runner in both ci.yml (push to main) and pr-check.yml (PRs),
then fail if git status is dirty. catches forgetting to regenerate a
.g.dart after editing a MobX store or @JsonSerializable model, which
analyze/test/build all miss (as #576 did).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a weekly + manual release-dryrun workflow that exercises the full store
pipeline without publishing: Android validates the AAB against Google Play
(validate_only), iOS builds a fully signed archive via match (readonly) and
skips the App Store upload. Both Fastlane lanes gain a dry_run option that
reuses the real release path so the dry-run stays faithful to it.
Also add release-mode compile checks (flutter build apk/ios --release) to CI
and PR checks to catch release-only breakage, pinning the JDK to match the
release toolchain. Trim ci.yml from a redundant 3-OS matrix to two
purpose-built jobs (analyze/test once on Linux, iOS build on macOS).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Workflows used subosito/flutter-action with no version, silently tracking
GitHub's latest stable. When stable rolled to 3.44.1 it broke the build with
no code change. Pin explicitly so builds are reproducible and Flutter upgrades
are a deliberate bump rather than a surprise.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
