ci: bump Codemagic Flutter to 3.44.5 to match GitHub Actions - #11672
Merged
Conversation
Every Codemagic mobile build has failed at `Get Flutter packages` since 15 Aug: The current Dart SDK version is 3.11.5. Because flutter_contacts 2.3.1 requires SDK version ^3.12.0 [...] version solving failed. Two commits, three days apart, neither wrong on its own. 35c146d moved GitHub Actions to Flutter 3.44.5 and left Codemagic on 3.41.9, so the two lanes began running different Flutter versions. 34e2ba8 (#11595) then bumped flutter_contacts to ^2.3.1, which requires Dart ^3.12.0 — fine on 3.44.5 (Dart 3.12.2), impossible on 3.41.9 (Dart 3.11.5). CI could not have caught it: #11595 was green because the GitHub lane was already new enough, and nothing checks the lane that was not. All eight pinned workflows were affected — every internal and store build path. Also updates the developer-facing copies of the same pin (setup.sh, setup.ps1, AppSetup.mdx, the two rayban docs), which would otherwise hand a new contributor a toolchain that cannot resolve this repo. The '3.41.9' left in rayban_dat_plugin_boundary_test.rb is fixture content inside a fake .flutter-plugins-dependencies blob, not a toolchain pin. xcode, cocoapods and java pins are unchanged. 3.44.5 rather than the 3.47.0 pub suggests: 3.44.5 is what GitHub Actions already runs green on this exact lockfile, so matching the working lane is the smaller change. Moving both lanes to a newer Flutter is its own decision. Verification, against this repo's unmodified pubspec.yaml/pubspec.lock: Flutter 3.41.x (Dart 3.11.0) — `flutter pub get` reproduces the identical version-solving failure. Flutter 3.44.5 (Dart 3.12.2, per `dart --version`) — `flutter pub get` prints "Got dependencies!" and leaves `git status` clean, so the lock does not drift. codemagic.yaml parses as YAML and all 8 pins read 3.44.5, asserted in code rather than by eye. make preflight — 11/11. Not verified: a real Codemagic run; I cannot trigger one. The failing step is `pub get`, which is what was reproduced above.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
kodjima33
pushed a commit
that referenced
this pull request
Aug 16, 2026
…1673) 92a2ff1 (merged as #11672) edited codemagic.yaml, changing the eight Flutter version pins to 3.44.5, without updating the reviewed digest fixture the release-process guard compares against. The guard is designed to fail exactly then, so Hygiene is now red on main and on every open PR. Both digests were recomputed with the check script's own functions (_read_security_bound_file + _sha256_bytes for the raw digest, _canonical_json + _sha256_text over the safe-loaded document for the semantic digest) against codemagic.yaml as merged at 94487a4: codemagic_raw_sha256 941fd7588a169eeb5307b8f90f76bfe874960365b8ca0e879dd9234373c5081a -> 826c7aba7465777a0965c2ab50b1fc12070f2aefbbb7b1d80e326355b21a206d codemagic_semantic_sha256 a2d952c0d27db55dcd558e49805f096d5a884a55d8db2fa124a61fa5315a5876 -> a72c79d0e2bec1339d777e3be3c928b1d0f5eeb39071467979b83537ae0ccf25 The only codemagic.yaml change these digests newly approve is that commit's 16-line version-pin diff; no workflow, credential, or publisher content changed, and the per-workflow contract checks in the same guard still pass unchanged. Verification: check-release-process-guards.py now reports zero errors locally (it reported the two digest errors before); its test file goes from 11 local failures to 9, the two digest-dependent tests now passing and the remaining nine being POSIX symlink/O_NOFOLLOW tests that fail identically on clean main under Windows and run properly on Linux CI.
mdmohsin7
added a commit
that referenced
this pull request
Aug 16, 2026
## What Every iOS archive has failed since #11672 merged: ``` xcodebuild: error: Could not resolve package dependencies: Failed to resolve dependencies Dependencies could not be resolved because 'firebase_crashlytics-4.3.2' depends on 'flutterfire' 3.11.0-firebase-core-swift and 'firebase_messaging-15.2.5' depends on 'flutterfire' 3.13.0-firebase-core-swift. ``` Disables Swift Package Manager at the project level, restoring the CocoaPods plugin resolution that has been shipping all along. Four lines in `app/pubspec.yaml`. ## Why it broke #11672 moved Codemagic from Flutter 3.41.9 to 3.44.5 to fix `pub get`. That was the right fix for the Dart constraint, but 3.44 also flips a default I did not check. From `flutter_tools/lib/src/features.dart`: ```dart // 3.41.9 const swiftPackageManager = Feature( stable: FeatureChannelSetting(available: true), // → off ); // 3.44.5 const swiftPackageManager = Feature( stable: FeatureChannelSetting(available: true, enabledByDefault: true), // → ON ); ``` 3.41.9 resolved iOS plugins through CocoaPods. 3.44.5 resolves them as Swift packages, which exposes a version skew that was **already in the repo and invisible under CocoaPods**: | Pinned in `app/pubspec.yaml` | Declares | |---|---| | `firebase_core: 3.13.0` | — | | `firebase_messaging: 15.2.5` | `firebase_core: ^3.13.0` | | `firebase_crashlytics: 4.3.2` | `firebase_core: ^3.11.0` | `firebase_crashlytics` is two minor versions behind the pinned core. CocoaPods tolerates that; SPM will not hold two versions of the same `flutterfire` package, so resolution fails outright. ## Why this fix and not the version bump The durable fix is aligning the Firebase plugins — tracked in #11676, with `firebase_crashlytics 4.3.5` as the release built against `firebase_core 3.13.0`. That is a runtime dependency change to a shipping app whose only real acceptance test is an iOS archive, so it should land deliberately rather than as a hotfix. This change instead restores the exact plugin resolution that was in production before #11672, which is the smallest thing that unblocks the release lanes. Placed in `pubspec.yaml` rather than as a Codemagic env var or `flutter config` call: the project manifest is first in Flutter's resolution order (project → global config → environment), so it fixes local builds and every CI lane from one checked-in place, instead of leaving contributors on 3.44.x to rediscover this. Flutter warns that disabling "will not be allowed in a future version", so #11676 is not optional — the comment in `pubspec.yaml` links it. `meta-wearables-dat-ios` is unaffected: it is a direct `XCRemoteSwiftPackageReference` in `Runner.xcodeproj`, resolved by Xcode independently of Flutter's plugin SPM integration. The failing log shows it fetching successfully before Flutter's step failed. ## Verification I have no macOS, so I cannot run the archive that failed. What I could prove locally, I did: - **The key is live and correctly spelled.** Negative control: setting `enable-swift-package-manager: "not-a-bool"` in this pubspec makes `flutter pub get` exit with ``` The "enable-swift-package-manager" property in "flutter: config:" in pubspec.yaml must be a boolean, but got not-a-bool (String) ``` That message is emitted from `_isEnabledAtProjectLevel` reading `flutterDescriptor['config']['enable-swift-package-manager']`, so Flutter is demonstrably reading this key from this file. A typo would have silently no effect; this rules that out. - `flutter pub get` with the real value — `Got dependencies!`, lockfile unchanged. - `app/test.sh` on Flutter 3.44.5 with the flag set — **1338 passed**, exit 0. - `make preflight` — 11/11. **Not verified: the iOS archive.** `.flutter-plugins-dependencies` reports `swift_package_manager_enabled: {ios: false, macos: false}` on Linux whether or not the flag is set, because `usesSwiftPackageManager` is `featureFlags.isSwiftPackageManagerEnabled && compatibleWithSwiftPackageManager` and the second term needs Xcode. So that file is not evidence either way here, and I am not citing it as such. The first real proof is the next Codemagic iOS build. ## Follow-up - #11676 — align the Firebase plugin versions and remove this flag. - Still unaddressed from #11672: nothing compares the Codemagic and GitHub Actions Flutter pins. Worth noting that a drift check would not have caught *this* one either — both lanes now agree on 3.44.5 and the SPM default bites both. The gap this exposes is different: a Flutter major/minor bump changes build-system defaults, and neither lane builds iOS in PR CI, so only a post-merge Codemagic run can catch it.
pull Bot
pushed a commit
to codingwatching/omi
that referenced
this pull request
Aug 16, 2026
Every iOS archive has failed since BasedHardware#11672: xcodebuild: error: Could not resolve package dependencies: 'firebase_crashlytics-4.3.2' depends on 'flutterfire' 3.11.0-firebase-core-swift and 'firebase_messaging-15.2.5' depends on 'flutterfire' 3.13.0-firebase-core-swift. BasedHardware#11672 moved Codemagic to Flutter 3.44.5 to fix `pub get`. 3.44 also flips a default I did not check: `swiftPackageManager` gained `enabledByDefault: true` on stable, so iOS plugins resolve as Swift packages instead of through CocoaPods. That exposes a skew already in the repo — firebase_crashlytics 4.3.2 declares firebase_core ^3.11.0 while firebase_messaging 15.2.5 declares ^3.13.0, against a pinned core of 3.13.0. CocoaPods tolerates it; SPM will not hold two versions of the same flutterfire package. Restores the plugin resolution that was in production before BasedHardware#11672. The durable fix is aligning the Firebase plugins (BasedHardware#11676, crashlytics 4.3.5 is the release built against core 3.13.0), which changes a shipping app's runtime dependencies and wants an iOS archive as its acceptance test, not a hotfix. Set in pubspec.yaml rather than a Codemagic env var or `flutter config`: the project manifest is first in Flutter's resolution order, so one checked-in place covers local builds and every CI lane. Flutter warns it will stop honouring this, so BasedHardware#11676 is not optional; the comment links it. meta-wearables-dat-ios is unaffected — a direct XCRemoteSwiftPackageReference resolved by Xcode independently of Flutter's plugin SPM integration, and the failing log shows it fetching fine before Flutter's step failed. Verification (no macOS here, so the archive itself is unverified): Negative control proves the key is live and correctly spelled — setting `enable-swift-package-manager: "not-a-bool"` makes pub get exit with 'The "enable-swift-package-manager" property in "flutter: config:" in pubspec.yaml must be a boolean', emitted from _isEnabledAtProjectLevel reading flutterDescriptor['config']. A typo would silently no-op; ruled out. flutter pub get with the real value — Got dependencies!, lockfile unchanged. make preflight — 11/11. .flutter-plugins-dependencies is NOT evidence here: it reports swift_package_manager_enabled false on Linux regardless, because usesSwiftPackageManager also requires Xcode. First real proof is the next Codemagic iOS build.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Every Codemagic mobile build has been failing at
Get Flutter packagessince 15 Aug:Bumps the eight Codemagic Flutter pins from
3.41.9to3.44.5, matching what GitHub Actions already runs.Why it broke
Two commits, three days apart, neither wrong on its own:
35c146d3fa(12 Aug, stabilize mobile and Swift release CI) moved GitHub Actions to Flutter 3.44.5 and left Codemagic on 3.41.9. From then on the two lanes ran different Flutter versions.34e2ba8e72(15 Aug, fix(app): migrate flutter_contacts to 2.x — 1.x crashes under UIScene #11595, migrate flutter_contacts to 2.x) bumpedflutter_contacts: ^1.1.9+2→^2.3.1, which requires Dart^3.12.0. It touchedpubspec.yaml,pubspec.lockand three call sites — correctly — and nothing else.version solving failedCI could not have caught this. #11595 was green on GitHub Actions because that lane was already on a Flutter new enough to satisfy the new constraint. The failure only appears on the lane whose version nothing checks.
Scope
All eight workflows with a Flutter pin were affected — every internal and store build path:
ios-internal-auto,android-internal-auto,ios-prod-testflight,macos-prod-appstore,android-prod-internal,ios-prod-patch,macos-prod-legacy-no-publish,android-prod-patchAlso updated the developer-facing copies of the same pin, which would otherwise hand a new contributor a toolchain that cannot resolve this repo:
app/setup.sh,app/setup/scripts/setup.ps1,docs/doc/developer/AppSetup.mdx,docs/rayban-meta-dat-setup.md,docs/rayban-meta-founder-acceptance.md.Left alone:
app/ios/test/rayban_dat_plugin_boundary_test.rb:233, where'version' => '3.41.9'is arbitrary fixture content inside a fake.flutter-plugins-dependenciesblob for a plugin-registration test, not a toolchain pin.xcode,cocoapodsandjavapins are unchanged.Why 3.44.5 and not 3.47.0
pubsuggests 3.47.0, but 3.44.5 is the version GitHub Actions already runs green on this exactpubspec.lock. Matching the lane that works is the smaller change; moving both lanes to a newer Flutter is a separate decision with its own verification.Verification
Reproduced and fixed locally on the real toolchains, against this repo's unmodified
pubspec.yaml/pubspec.lock:flutter pub getfails with the identicalversion solving failederror.dart --version):flutter pub get→Got dependencies!, andgit statusis clean afterwards, so the lockfile does not drift.app/test.shon 3.44.5 at this branch's base — 1338 passed, whole suite green on the toolchain this PR moves Codemagic to.codemagic.yamlparses as YAML and all 8 pins read3.44.5; asserted programmatically rather than by eye.make preflight— 11/11.Not verified: the Codemagic build itself. I cannot trigger one, so the first real proof is the next build after merge. The failing step is
pub get, which is exactly what was reproduced above.Follow-up (deliberately not in this PR)
Nothing checks that
codemagic.yamland the GitHub workflow pins agree, which is the actual reason a routine dependency bump took out every release lane while CI stayed green. A manifest check comparing the two would have failed #11595 in CI instead of at build time. Left out to keep this PR to the unblock; happy to add it separately.