New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvements to caching #265
Conversation
In order to reduce the extra work that happens when you update your pubspec.lock, don't use `hashFiles('**/pubspec.lock')` in the hash of the flutter installation, and separately cache the `.pubspec-cache`. Also return the `.pub-cache` to `$HOME`, since it's not part of the tool installation.
@@ -91,6 +93,8 @@ CHANNEL="${ARR_CHANNEL[0]}" | |||
[[ -z $ARCH ]] && ARCH=x64 | |||
[[ -z $CACHE_PATH ]] && CACHE_PATH="$RUNNER_TEMP/flutter/:channel:-:version:-:arch:" | |||
[[ -z $CACHE_KEY ]] && CACHE_KEY="flutter-:os:-:channel:-:version:-:arch:-:hash:" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's remove -:hash:
from here? It makes self-hosted runners to re-download flutter from cache every time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vladimir-goldobin I'm not clear as to why :hash:
is a problem here? As I understand it, that's the hash from the manifest (e.g. https://storage.googleapis.com/flutter_infra_release/releases/releases_macos.json) and the hash of the release, independent of the runner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think :hash:
shouldn't be a problem here.
Thanks for this improvements @jorgenpt |
PUB_CACHE
before invoking the action to control where the .pub-cache directory lives