ci(repo): route every Flutter setup through setup-flutter - #2952
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review. 📝 WalkthroughWalkthroughThe local Flutter setup action now accepts configurable version, channel, and SDK cache inputs. Repository actions and workflows now use this local action instead of configuring ChangesFlutter setup centralization
Suggested reviewers: Merge Risk: ⚪ Minimal · up to The change centralizes Flutter setup across CI workflows and preserves the beta workflow’s newest-beta behavior. No actionable merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Five call sites configured subosito/flutter-action independently and their
cache keys had drifted into two shapes:
setup-flutter: flutter-:os:-:channel:-:version:-:arch:
everywhere else: flutter-:os:-:channel:-:version:-:arch:-:hash:-<pubspec.lock hash>
So the same SDK gets stored twice. Both of these are live right now:
flutter-linux-stable-3.47.3-x64 1640 MiB
flutter-linux-stable-3.47.3-x64-e8113bf...-b09b477... 1640 MiB
That is 1.6GB of a 10GB repository allowance that currently sits at
~9.05GB, so it evicts other caches.
setup-flutter now takes optional flutter-version and channel inputs and
owns the key shape; the other call sites pass only what differs.
legacy_version_analyze still pins 3.44.0 and so still gets its own entry,
which is correct rather than duplication.
Two behaviour changes worth noting:
- release_publish used a bare flutter-action with no cache and no
version pin. It now caches and resolves 3.x like everything else.
- beta_version_analyze passes an empty flutter-version so it keeps
tracking the newest beta whatever its major version, rather than
inheriting the 3.x default.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cd51dc5 to
4389599
Compare
beta_version_analyze runs once a week and GitHub expires cache entries after 7 idle days, so an SDK entry is at the expiry boundary by the next run — and a newly released beta changes the resolved version, and so the key, making it a certain miss. It stored ~1.6GB nearly every run for almost no restores. setup-flutter gains a cache-sdk input for this, and now enables pub caching explicitly so turning the SDK cache off keeps it. The pub key carries no channel or version, so beta shares the entry the stable jobs already populate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Names the failure mode rather than the mechanism: inheriting the shared action's 3.x default would keep the weekly beta check on 3.x betas. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
🎯 Goal
Reclaim ~1.6GB of the repository's 10GB Actions cache allowance, which currently sits at ~9.05GB and therefore evicts caches other jobs need.
🛠 Implementation details
subosito/flutter-actionindependently and their cache keys had drifted into two shapes —flutter-:os:-:channel:-:version:-:arch:insetup-flutter, and…-:hash:-${{ hashFiles('**/pubspec.lock') }}everywhere else — so the same SDK is stored twice. Both of these are live right now:flutter-linux-stable-3.47.3-x64(1640 MiB, master) andflutter-linux-stable-3.47.3-x64-e8113bf…-b09b477…(1640 MiB, PR ref).setup-flutternow takes optionalflutter-versionandchannelinputs and owns the key shape;update_goldens(×2),release_publish,legacy_version_analyze,beta_version_analyzeandactions/panapass only what differs. Composite-in-composite is already used byactions/allure-launch, soactions/panais not new ground.legacy_version_analyzestill pins Flutter 3.44.0 and so still gets its own SDK entry — correct, not duplication.release_publishused a bareflutter-actionwith no caching and no version pin, and now matches everything else;beta_version_analyzepasses an emptyflutter-versionso it keeps tracking the newest beta whatever its major, instead of inheriting the3.xdefault.☑️ Verification
Not yet run — this is a draft. All six touched files parse as YAML, and no direct
subosito/flutter-actionusage remains outsidesetup-flutter. The keys can only be confirmed by landing this and watching the cache list settle to one SDK entry per os/channel/version/arch;update_goldens,release_publishandbeta_version_analyzeare dispatch/cron/schedule-triggered, so they will not exercise themselves on this PR.Unrelated to this change,
gradle-Linux-…is 2.92GB — the single largest entry, and a bigger prize than this PR if the cache limit keeps biting.☑️Contributor Checklist
General
☑️Reviewer Checklist
🤖 Generated with Claude Code
Summary by CodeRabbit