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

Add content hashing as a versioning strategy #164

Merged
merged 5 commits into from
May 9, 2019
Merged

Conversation

jonabc
Copy link
Contributor

@jonabc jonabc commented May 8, 2019

closes #129

This PR adds file contents hashing as an alternative versioning strategy for the go and manifest sources.

For the manifest source we already track a specific list of source files that make up the dependency 👍 .

For the go source it's a little more complicated - see the issue for more details - and licensed will hash all files in the import path directory. I took this approach instead of enumerating *Files properties from the go list output to include metadata files (including LICENSE files) if available.

I'm using a pure ruby implementation of the xxHash algorithm via the ruby-xxHash gem. It's not the most recent version of the algorithm (which is xxH3) but it is still much faster than an MD5 hash and should see fewer or equal collisions to that algorithm. For the size of the content in my tests it was significantly faster to use content hashing as it was to obtain the Git SHA.

@jonabc jonabc merged commit 908f0de into master May 9, 2019
@jonabc jonabc deleted the content-hash-versioning branch May 9, 2019 00:18
@jonabc
Copy link
Contributor Author

jonabc commented May 11, 2019

content hashing can be enabled with the following setting in a licensed app configuration

version_strategy: contents

@jonabc jonabc mentioned this pull request May 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Investigate alternative version ideas for manifest-sourced dependencies
1 participant