release to GitHub on version tag push and check version.go

[qrkourier]

Tune release workflow to check or set ziti-agent/cmd/common/version.go. My preferred approach is for a workflow triggered by PRs based on default branch to fail if version stamp in ziti-agent/cmd/common/version.go already exists in GitHub releases API.

That is sufficient to prompt devs to increment version appropriately in their branch.

It's more complicated to have release automation set the version stamp in ziti-agent/cmd/common/version.go.

[qrkourier]

Part of this task is for release workflow to set release version in GitHub API based on pushing a tag, and for that job to fail if the version does not match ziti-agent/cmd/common/version.go.

[qrkourier]

Now I see the release workflow is triggered by push to default branch and gets the version from a binary built during the same job and pushes to Hub without updating GitHub releases API. This ensures that ziti-agent/cmd/common/version.go in the default branch always matches newly published release version tags in Hub, but does not prevent clobbering existing release versions in Hub if ziti-agent/cmd/common/version.go is not incremented by mistake, and releases must be immutable (never re-released with the same version).

Let's consider releasing to GHCR or GitHub Releases API or both Releases API and some OCI registry. Hub is fine. GHCR (GH Packages) is fine. Whichever's easiest for devs is fine.

It's truly helpful to explore release versions in GH Releases API which is displayed in the GH repository view. This makes it much more convenient to compare versions' sources.

[dariuszSki]

Sure, if you want to work on that, please go ahead.