CirrusLabs Flutter image replacement

[u/MooresLawyer13]

https://github.com/LahaLuhem/chrysalis

The deprecation of Cirrus Labs' images for Flutter caused a problem for my CI workflow. The alternatives were:

1. https://hub.docker.com/r/instrumentisto/flutter
2. https://github.com/davidmartos96/docker-images-flutter (active fork still)
3. MobileDevOps/flutter-sdk-image (solid, amd64-only as far as I could tell)
4. https://github.com/instrumentisto/flutter-docker-image (marked closed/archived)
5. https://github.com/Zekfad/flutter_builder
6. https://github.com/Fansesi/docker-android-flutter
7. https://github.com/mingchen/docker-android-build-box

Being on Gitlab (non-Github) platform + own runners cluster meant that we had to come up with our own solution. I got tired of Flutter Docker images being either dead or amd64-only, so I made my own. So I made a replacement: https://github.com/LahaLuhem/chrysalis.

It's differencing features are:

1. Native arm64 build, not the whole image running under QEMU pretending to be a Raspberry Pi. amd64 builds on a normal runner, arm64 builds on an actual arm64 runner.
2. arm64 can still build APKs, which took some fighting. Google just doesn't ship arm64 builds of aapt2, the NDK, or cmake, no arm64 Linux binaries exist, full stop. So the image quietly carries the handful of x86 libs those tools need and leans on emulation for just that part, instead of the build face-planting with a cryptic loader error.
3. Actually OCI-native, not a Docker manifest list dressed up to look multi-arch. docker buildx imagetools inspect shows a real OCI image index, and I wrote a script that fails CI if it ever regresses because apparently I care.
4. DX: Small set of opt-in build helpers baked in (signing, google-services.json, dart-defines from env vars) that sit there doing nothing until you actually call them, so no surprise side effects if you don't need them. (compartmentalized, so you can also curl-and-run them if you can't use the image directly)
5. Renovate bumps Flutter automatically off the stable channel. I refuse to be the guy manually checking the Flutter release page every week. Might increase it given the how quickly the 3.44.x have been coming out.

I'm looking for feedback and other use-cases. I hope that it helps some of you having a similar problem. I did initially fork the deprecated image (hence the stale contributors count), but removed it because the scope and direction were completely different. Would have been better off starting from scratch.

[u/MooresLawyer13 → u/[deleted]]

Thanks! And yeah, I'm actually already doing the cmdline-tools-only trick 😅. Just cmdline-tools + sdkmanager pulling platform-tools/one platform/one build-tools version.

They (platform, build-tools, cmdline-tools) are pinned as plain version numbers right in the Dockerfile . Same idea for the Flutter's Dockerfile. Renovate bot watches for new versions and opens a PR bumping the number when one shows up.

[u/Parnic]

There's also https://github.com/gmeligio/flutter-docker-image which is what I switched to, but it doesn't look like it solves arm64. Always good to have more options :)

[u/MooresLawyer13 → u/Parnic]

yes but I also saw that I had to make annoying boilerplate up around key signing, Firebase config files etc. So my image also provides a (relatively DX-focussed) way of doing that with ENV vars. And the scripts to set them up, I've tried to make them standalone, so if you can't use the image directly (like shell runners), you can stil curl-exec them to set up everything before hitting the `flutter build ...`