Skip to content
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

Merged
merged 1 commit into from May 19, 2023

Conversation

stevenh
Copy link
Contributor

@stevenh stevenh commented May 17, 2023

Use 8 character hash components to reduce the key length, making it more readable.

Fixes #97

@stevenh
Copy link
Contributor Author

stevenh commented May 17, 2023

This is stacked on top of #142

Example output from test run with hash-length: 8

Restore Key:
      v0-rust-test-08480e93
  Cache Key:
      v0-rust-test-08480e93-e9d0959e

Copy link
Owner

@Swatinem Swatinem left a 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 🤷🏻‍♂️

@stevenh
Copy link
Contributor Author

stevenh commented May 17, 2023

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?

@Swatinem
Copy link
Owner

for small projects the impact wouldn't be to bad, but for large projects it could cause noticeable delays

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. :-)

@stevenh
Copy link
Contributor Author

stevenh commented May 18, 2023

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
@stevenh stevenh changed the title feat: hash length configuration chore: use 8 character hash components May 18, 2023
@stevenh stevenh marked this pull request as ready for review May 18, 2023 21:10
@Swatinem Swatinem merged commit bb80d0f into Swatinem:master May 19, 2023
20 checks passed
@max-sixty
Copy link
Sponsor

Thanks @stevenh !

@stevenh stevenh deleted the feat/hash-length branch May 20, 2023 11:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Reduce key length?
3 participants