-
-
Notifications
You must be signed in to change notification settings - Fork 105
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
chore: use 8 character hash components #143
Conversation
This is stacked on top of #142 Example output from test run with
|
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.
I would just always truncate this to 8 chars (aka 4 bytes of hash value) instead of making it configurable.
This is not supposed to be a cryptographic hash, even in the unlikely case of a 1-in-4-billion collision, the worst thing that can happen is that the build is taking a longer time because it does not have the right artifacts. So what 🤷🏻♂️
The reason I made it configurable was to keep compatible with existing caches. Yes this would be one time change when it pulls the new version and for small projects the impact wouldn't be to bad, but for large projects it could cause noticeable delays. As this is more a quality of file change and all other caches use the full hash, felt like keeping the standard hash as the default would be the best course. Thoughts? |
A cache by definition is best-effort. There is never a guarantee, just a hit-rate to optimize for, so a full rebuild every once in a while does not hurt. :-) |
Will update this once we have the key stability PR landed😊 |
Use 8 character hash components to reduce the key length, making it more readable. Fixes Swatinem#97
Thanks @stevenh ! |
Use 8 character hash components to reduce the key length, making it more readable.
Fixes #97