test(ci): cache key names must include enough information to expire correctly #17943
Conversation
the flutter action caches things by default with a cache key name that is not specific enough that it will expire if a new version comes out alter the key naming to include all pertinent details about the flutter version (or pub version) being cached so that new versions will get a fresh cache see https://github.com/subosito/flutter-action?tab=readme-ov-file#caching in combination with knowledge that github actions/cache produces *immutable* caches so they will never update meaning you must make a new cache if a new version comes out
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. |
the Podfile.lock files are not committed to the repository so they cannot be used for cache key disambiguation via hashfiles - they generate an emptry string however, the real dependencies for Pods are driven from the pubspec, so hashing the pubspec.lock file should be sufficient to generate fresh caches when Pods change
|
Here's how I saw this on the caches page, and the assumption is that after merge and a CI run the keys will be fixed. Square boxes are the flutter/pub names that are overly general. Those caches will never be updated or expire because they will hit but all caches are immutable so the hit means it will remain unchanged for eternity. Adding all the version / arch etc info makes for an unambiguous key name which will change as flutter changes. Circle is similar problem but for Pods, and it was because the file that should have made a unique key when it was hashed was 
|
2 participants
Description
After the initial CI caching best practices PR merged I noticed a problem that was hidden by the LRU thrashing before
https://github.com/firebase/flutterfire/actions/caches?query=sort%3Acreated-asc
See the flutter- and pub- caches? They are not unique keys, they will never update.
The same problem was present for the Pods caches - but for a different reason, in that case the Podfile.lock files don't exist so they cannot be used to generate a cache key name part. I deferred to the pubspec.lock file as it drives the Pods dependencies anyway
the flutter action caches things by default with a cache key name that is not specific enough that it will expire if a new version comes out
alter the key naming to include all pertinent details about the flutter version (or pub version) being cached so that new versions will get a fresh cache
see https://github.com/subosito/flutter-action?tab=readme-ov-file#caching in combination with knowledge that github actions/cache produces immutable caches so they will never update meaning you must make a new cache if a new version comes out
Related Issues
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]).This will ensure a smooth and quick review process. Updating the
pubspec.yamland changelogs is not required.///).melos run analyze) does not report any problems on my PR.Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?