Release workflows should fail early in case of Github/Makefile tag mismatch

[r0mant]

Scenario:

• Update version in Makefile to, say, v1.2.3-dev.cloud.1.
• Push actual tag to Github v1.2.3-cloud.dev.1.
• Watch release pipeline build some architectures but fail later down the path.

Release workflows should detect this error early and fail with a clear error.

[camscale]

@r0mant How are they pushing a different tag than what is in the Makefile? You just run make update-tag and it uses the VERSION set in the Makefile. You have to do extra work to get this wrong and I'm not sure why anyone would?

I do plan do fix this - I've been thinking about this yesterday - I don't think we need to tag dev builds at all any more. We used to trigger the build off the tag but since we do not any more, we should just be able to do make dev-build VERSION=1.2.3-dev.username.foo.1 or similar and have it build the current commit. I have some other thinking about this which I'll detail shortly.

This issue is perhaps the same as https://github.com/gravitational/teleport.e/issues/2021 (Fix regressions in release pipeline) which is what I've started working on, but there is a lot of churn in the release workflows with the *-stage work that I've been letting that settle first. That issue is a touch more broad though given it is also about publishing to the release server.

[zmb3]

You have to do extra work to get this wrong and I'm not sure why anyone would?

I'm the one who did this. I was making a dev build off of a dev branch, so rather than waiting for a PR to merge to a release branch and tagging that commit, I tagged my dev branch directly.

• Updated makefile with dev version
• Ran make update-version
• Committed the results
• Before running make update-tag, realized I wanted to change the tag.
• Updated makefile to alter tag.
• Ran make update-version
• forgot to commit results
• Ran make update-tag.

The final invocation of make update-tag pushed the tag that matched my local version, but the latest commit pushed to origin still had the original version number in it.

One way to prevent this would be for make update-tag to fail if your local git state is not clean. That would have prevented me from hitting this issue and make me realize I need to commit my version changes before proceeding.

[doggydogworld]

I'll add two changes for this.

• Update the workflow to exit early if it detects this error.
• Update the Makefile to exit early if it detects any uncommitted and unpushed changes by default.

It should provide it a good developer UX to fail early rather than wait for the workflow to kick off before they realize their mistake. The workflow checking the version should be a good catch all just in case the error does occur despite our best efforts.