Add sha256sums.txt to releases

[martinlindhe]

Our appveyor script should be updated to generate a checksum file, something like https://github.com/prometheus/prometheus/releases/download/v2.0.0-beta.0/sha256sums.txt

Useful for http://scoop.sh/ or https://chocolatey.org/ (?)

[carlpett]

Looking at Appveyor's docs, it is not clear to me that we could achieve that exact layout, with all the file hashes in the same file. As far as I understand, the artifacts from AppVeyor are pushed as they are ready, and there is no synchronization point where we have access to all the files from all the builds in the matrix and can produce that file. @FeodorFitsner, is that correctly understood?

Prometheus promu builder does this by building all the releases in the same run, so they do have all the binaries. We could ditch the matrix and just cross-compile the 386 version, at the cost of parallel builds. On the other hand, our builds take ~30s, so maybe that isn't such a big deal.

[martinlindhe]

I suspected this was the case :-/ Yea, since our build is pretty small maybe we could scrap parallel builds.

[martinlindhe]

Possibly we could make do using goreleaser.
Instead of letting appveyor produce releases, then one would build locally.
(It would still be very good if appveyor can produce build artifacts from each commit)

goreleaser creates and uploads sha256sums.txt, cross-compiles for Windows (and more that is not useful for this project).

https://goreleaser.com/

Been using it for a bit with success on this project: https://github.com/martinlindhe/gohash/releases

[carlpett]

@martinlindhe Is there a difference between that approach and using promu without the build matrix as we discussed previously?
I'm not sure I understand "Instead of letting appveyor produce releases, then one would build locally.", are you suggesting that release binaries should be built on someone's local machine and uploaded?

[martinlindhe]

@martinlindhe Is there a difference between that approach and using promu without the build matrix as we discussed previously?

I think promu would be a better approach then. Was just posting about a tool that resolves this for us.

are you suggesting that release binaries should be built on someone's local machine and uploaded?

That is indeed one usage pattern for goreleaser. They also document CI integration on their homepage: https://goreleaser.com/#continous_integration

[carlpett]

I don't have a strong opinion of promu vs goreleaser, just wondered if I was missing something :)
Re building locally, I do have a strong opinion, however. I do not think it is a good practice to build public releases on a personal machine. It is no longer (somewhat) simple for an end user to know what is in the binary, and the possibility of human errors (having some local change etc) is much higher.

[martinlindhe]

@carlpett just to respond to your comments (i also don't have a strong opionon of this)

I do not think it is a good practice to build public releases on a personal machine

Is this with regards to viruses and stuff?
I am personally positive to local builds, as it is a requirement for general improved security measures such as reproducible builds.

(This pr is about adding hashes to builds, which itself is to help improve "trust" in the binaries). I am not for reducing security / trust.

It is no longer (somewhat) simple for an end user to know what is in the binary, and the possibility of human errors (having some local change etc) is much higher.

Not sure I agree that the release process must be comprehensible to a end user.
goreleaser is not indended for just building a .exe, it is for releasing binaries to github.

Goreleaser looks at your git repository and works with it.

Which means; you can only build binaries when git head is on the same revision as the release tag, and git is not in a dirty state.

So in order to use it, you basically

$ git tag -a v0.1.0 -m "First release"
$ git push origin v0.1.0
$ export GITHUB_TOKEN="xxx"
$ goreleaser

and it will do the rest

[carlpett]

This is taking a slightly philosophical turn, and might get subjective, but here is my reasoning:

Is this with regards to viruses and stuff?

Yes, as well as the lack of control over the installed versions of compilers etc.

I am on the contrary positive to local builds, as it opens up trust in things like reproducible builds.

Then I think we have the same ideal :) I fully agree that builds should be trusted and reproducible. But I would argue that since the CI system configuration is stored along with the code, building it on a "trusted" platform (depending on how much you trust AppVeyor et al) with the exact build steps checked out together with the code, is "more" reproducible than having a local Makefile or similar.

Not sure I agree that the release process must be comprehensible to a end user.

What I meant was tied in with the previous idea - the user can check the build logs from this "trusted" build platform and verify that things were built as expected.

Which means; you can only build binaries when git head is on the same revision as the release tag.

This doesn't consider untracked source files that may be lying about, right? It is pretty easy to miss new files when stashing, for example (been there, done that).

But again, these aren't hard and simple truths.

[martinlindhe]

But I would argue that since the CI system configuration is stored along with the code, building it on a "trusted" platform (depending on how much you trust AppVeyor et al) with the exact build steps checked out together with the code, is "more" reproducible than having a local Makefile or similar.

Personally, I would like to be able to reproduce the exact binary locally as AppVeyor or travisCI produces (even better if i can cross-compile, since my main OS is not Windows) . Then I can know the generated binary is good by elimination of influence.

I can agree Makefile is a bit arcane, but I find them handy ;-)

This doesn't consider untracked source files that may be lying about, right? It is pretty easy to miss new files when stashing, for example (been there, done that).

It does. If "git status" reports "working tree clean" then goreleaser is happy.

[carlpett]

Okay, I think we've taken this as far as is valuable (and perhaps a bit longer) :)
To turn back to the actual topic - I see three options to get checksums available in the releases:

1. Keep using promu, cross-compile instead of using build matrix, let promu generate checksums.
   Pros:
   + Small change
   + "Prometheus-like", familiar to other prometheus contributors (although how much actual value this provides is unclear, there isn't much cross-over)
   Cons:
   - Lose some build speed due to lack of build matrix
   - Tests aren't run on x86 (given how little tests we have, probably not very much value lost)

2. Switch to goreleaser, otherwise as 1.
   Pros:
   + Not sure, haven't used. Please add
   Cons:
   - Same as for 1.
   - Larger change than 1.

3. Keep current approach in full, add checksums files for each specific file (ie wmi_exporter-amd64.exe.sha256sum)
   Pros:
   + Extremely simple change
   + Easily support multiple hash types (to whatever value that brings)
   Cons:
   - Unsure of support in tools such as Chocolatey for such checksum files?

Are there any other options? Did I miss any pro/con in this summary?