From c11c79b0c5b63e6761eb724b32212eb727efdff5 Mon Sep 17 00:00:00 2001 From: jwinterm Date: Sat, 19 Sep 2026 14:13:39 -0400 Subject: [PATCH] ci(windows): refuse a drifted Flutter, and let provisioning notice one Windows built 1.0.3 against Flutter 3.38.5 while every other platform used 3.32.0. Dart 3.10 removed the _macros package, so pub could not solve hive_generator against build_resolvers and the build died in dependency resolution, on the same commit Android and Linux had just built cleanly. The SDK was not missing. C:\flutter is exactly where provisioning puts it and exactly what PATH resolved; it had been upgraded in place. Provisioning never corrected it because it skipped on Test-Path alone, so a drifted SDK was reported as done every time it ran. It now compares the version and replaces the SDK when it does not match, which is the actual fix and the reason this went unnoticed for however long the machine has been ahead. The workflow stops guessing. My first attempt installed Flutter per build via subosito/flutter-action, which fails on this runner anyway because its setup script needs jq, and which would have downloaded a gigabyte every run to work around a machine provisioning already owns. It now refuses early and prints what is wrong and which script to run. A build machine's toolchain must not decide which dependencies resolve, and when it has drifted the build should say so rather than fail eighty steps later inside pub. No app code changes; hash-bags-ios-1.0.3 stays at 0697f41c7. Android and Linux artifacts from that commit are unaffected. --- .github/workflows/build-windows.yml | 41 ++++++++++++++++++----------- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/.github/workflows/build-windows.yml b/.github/workflows/build-windows.yml index 5c3806f4a..9b511daee 100644 --- a/.github/workflows/build-windows.yml +++ b/.github/workflows/build-windows.yml @@ -171,23 +171,34 @@ jobs: # hive_generator against build_resolvers and the build died at exit 69 # long before it compiled anything. A build machine's drifting toolchain # must not decide which dependencies resolve. - - name: Check Flutter 3.32.0 - id: flutter_check + - name: Require Flutter 3.32.0 run: | - if command -v flutter >/dev/null && flutter --version 2>/dev/null | grep -q "3\.32\.0"; then - echo "installed=true" >> "$GITHUB_OUTPUT" - flutter --version - else - echo "installed=false" >> "$GITHUB_OUTPUT" - fi + set -e + ver="$(flutter --version 2>/dev/null | head -1 || true)" + echo "runner has: ${ver:-}" + case "$ver" in + *3.32.0*) exit 0 ;; + esac + cat >&2 <<'MSG' - - name: Install Flutter 3.32.0 (if missing) - if: steps.flutter_check.outputs.installed != 'true' - uses: subosito/flutter-action@v2 - with: - flutter-version: '3.32.0' - channel: stable - cache: true + Refusing to build: this runner's Flutter is not the pinned 3.32.0. + + Every other platform is pinned, Linux and Android by the + cake_wallet debian13-flutter3.32.0 image and iOS by installing it, + so a drifted Windows SDK breaks this platform alone and does it + during dependency resolution rather than at compile time. + + Fix it on the runner rather than here. Installing an SDK per build + would download a gigabyte to paper over a machine that provisioning + is supposed to own, and subosito/flutter-action cannot do it anyway: + its setup script needs jq, which this runner does not have. + + powershell -File scripts\windows\setup-windows-runner.ps1 + + That now checks the version rather than only that flutter.bat + exists, which is why it had been reporting a drifted SDK as done. + MSG + exit 1 # ---- Toolchain sanity ------------------------------------------------ # Our self-hosted runner has Flutter / Rust / VS Build Tools / Inno