automate releases

[tobert]

Now that otel-cli has a good functional testing story, it's time to finally automate the last bits of the release process to get my computer out of the loop. I believe the remaining steps are something like this:

• create a new token with permissions to write to packages and releases
• set up a new GH Action that fires on new tags
  • build the release and run a go test -v which will run functional tests to validate the tag
    • current tests already do this
  • run goreleaser and it will do the rest
    • this must depend on a successful functional test

Once this is complete, a release can be made by tagging a sha and pushing tags, so package & release write access can be restricted to actions only.

[tobert]

Also the release build should set the linker flags with the tag version and shas. See: https://github.com/equinix-labs/otel-cli/blob/92a6f0acdf4affe4f6a7f1127f00cb44c57bc2f7/.github/workflows/ci.yml#L21

[tobert]

goreleaser should be setting the three linker flags automatically for release builds but for clarity there are three: main.version, main.commit, and main.date. These are printed by the otel-cli version subcommand and are invaluable for debugging.

The variables are defined in main.go: https://github.com/equinix-labs/otel-cli/blob/main/main.go

[displague]

Instructions are in the Releases section of the README.md. A GitHub action could be used to trigger the tag and release.

In other Equinix and Equinix Labs projects, Conventional Commits and Semantic Release have been introduced to simplify this process and ensure that the correct semver revision is applied based on the commit messages. CI will fail of conventional commits are not used. Maintainers reviewing PRs must ensure the prefixes (feat!:, fix:, chore(build):, etc) match the content of the PR.

The Equinix Go SDK and Terraform providers follow this pattern.

[tobert]

Releases follow semantic versioning since v0.0.1 and I've been writing a CHANGELOG.md for the last few releases. There have been no other maintainers to coordinate with so I feel the conventions are not as valuable as they are in a larger project context. For this project, releasing on tag push makes the most sense to me.

I now work on this in my personal time for free, and would prefer to not have the overhead. My feeling is that choices about how to maintain as a team should be made by that team when/if it materializes. For now, keeping the barrier to submitting & reviewing PRs low is paramount.

[auscompgeek]

An on-push GitHub Actions workflow should have write access to packages and releases, no need to mint a personal token. You may want to explicitly specify the permissions though. https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token