cut releases on CI, when the version number in version.json is changed

[marten-seemann]

Implementing the solution suggested in protocol/.github#158.

cc @mvdan

[marten-seemann]

Interesting. The releaser workflow is failing as it thinks that the intention of this PR is to increment the version number. I guess we need to special case the initial deployment.

[mvdan]

Or maybe it can learn to tell when the "added" version is already publicly released?

[marten-seemann]

Or maybe it can learn to tell when the "added" version is already publicly released?

Yes, but I'd like to prevent version downgrades. We could match against the highest version in go list -m -versions.

[marten-seemann]

We could match against the highest version in go list -m -versions.

Implemented it like this. Seems to work.

[marten-seemann]

I just pushed a major update to this PR: As discussed in protocol/.github#158 (comment), we probably don't want to give gorelease the control to block a release by failing our CI build.
Instead, we'll just post a comment on the PR containing the output of gorelease. We can then decide if we want to go along with its recommendations or if we have good reasons to make a different decision.

This also allows to split up the workflow into two different workflows: The pull_request workflow runs gorelease and posts the comment, and the push workflow tags the release and pushes it to GitHub.

[marten-seemann]

Closing, as this will be rolled out as part of the Unified CI Setup soon.