Glide: Hash verification should be an error (and exit with non-zero)

[gm42]

When running builds, I see:

$ glide install --delete --force
[WARN] Lock file may be out of date. Hash check of YAML failed. You may need to run 'update'

I would like to make hash verification mandatory instead of optional, because automated systems don't read warnings in the error/standard output.

I think we should have an option like --verify-hash or similar to enable this behaviour, as right now glide cannot be used safely in a continuous integration pipeline for this problem.

[mattfarina]

@gm42 When the hash was originally put in it was mandatory. This ended up causing problems (even though it shouldn't have). I like the idea of adding this back in to some degree.

Are you up for a pull request to add this? Or, should someone else do it?

[gm42]

@mattfarina yes I can follow up with a PR, but not earlier than +12h from now.

I will add it as an option --verify-hash, is that OK?

[joesis]

What the hash and updated field in glide.lock kept annoying me is frequent code conflict. Say if I ran glide up or added a package in a feature branch, and there was another commit in master updated glide.lock too, manual resolution is always required when merging, just because of the two fields. I would rather suggest removing these two fields completely, as glide.lock should always be in version control and be the final truth for CI or production build, and updated can always be derived from the file timestamp.

[bkleef]

@gm42 did you ever implement --verify-hash? IMHO CI/CD should fail on failing hash check. To do so we need a flag like that.

[gm42]

@bkleef I did some work, then stopped halfway. I think now it should be picked again from scratch due to code changes in master

[mattfarina]

I'm still open to merging a change that does that.