Automatically create a pre-release for each merge to master

[lalten]

This PR changes the Github Actions CI to automatically create a pre-release commit with all artifacts, for every push to master.

It does this by using the gh cli instead of the softprops/action-gh-release@v1 from the Marketplace. See https://docs.github.com/en/actions/using-workflows/using-github-cli-in-workflows and https://cli.github.com/manual/gh_release for more info on that.

This will also change the version information used in the runtime to point to that release.
The date of the version information is queried once and stored to a file instead of being regenerated. In theory this helps avoid a date rollover problem, in practice there are still multiple GH Actions runners so it won't actually help much in this case.
I guess one could take the date of the commit instead of the date of the build. However the commit date may be anything and doesn't even have to be anywhere close to the build time. It's certainly nicer to have monotonically increasing build tags, so the build time is still a better choice IMO.

Providing many releases / a continuous deployment is better than a single, changing release on a continuous tag because it allows consumers of the release to depend on (the artifacts of) a specific version and ensure artifact integrity using file hashes. This is very important for Bazel builds, which put a focus on reproducibility and determinism.

I tested the change by forking the repo, and commenting out the line that restricts releases to only master pushes (so it would release for every PR commit as well).

The release itself looks something like this: https://github.com/lalten/static-tools/releases/tag/build-2022-09-23-2a69ce3

[probonopd]

Very cool @lalten, thanks a lot!

If I understand it correctly, we can close #15?

[probonopd]

Can we get it to always post to a newly created continuous tag, so that a) the old builds are deleted automatically once we have a new one, and b) people can download from a never-changing URL? Resulting in something like #15?

Providing many releases / a continuous deployment is better than a single, changing release on a continuous tag because it allows consumers of the release to depend on (the artifacts of) a specific version and ensure artifact integrity using file hashes. This is very important for Bazel builds, which put a focus on reproducibility and determinism.

Hmmm. I guess this is the opposite of what I am after - not having to keep around old builds, which people might still be using instead of the latest successful build... can we at least change it so that no more than, say, 5 builds are kept around?

[probonopd]

That did not go well. We ended up with multiple releases for the same build.

[lalten]

Ah, I did not actually see #15, thanks for the link. I don't think it's a good idea to delete releases. As I said, in the Bazel world it is very important to have reproducible builds. That's not possible if the releases change or disappear.

As for the multiple releases being created, that is indeed unexpected. Note that there is only one that is actually visible, the others are Drafts.

I think what may be happening is that only the first parallel job will create the release, for the others the gh release create command will fail but still create a Draft. If the return code is nonzero we do run the gh release upload instead, which makes sure that the artifacts from the other parallel builds are attached to the single release.

[lalten]

For my purposes, I'll also be happy if you just create an official release every once in a while that you keep around. A continuous build will not work for me. In fact, Bazel will fail and cancel your build if it downloaded a third-party dependency that has a different SHA than expected.

[lalten]

I fixed the problem that caused the additional Draft releases. I'm going to merge this into my fork and use that for the releases I need. Let me know if you'd like to merge that here too.
Next I'm going to do the build .yml simplifcation I did in the type2-runtime repo but I'm not going to be able to make a PR for this repo because they'll be out of sync.

[probonopd]

I don't think we should do releases other than continuous automatically. From time to time, we may do manual releases of well tested builds.