Changes for GHA and release workflows

[mikelolasagasti]

• Use latest stable Go release for all workflow tasks. setup-go will get the latest stable version from the go-versions repository manifest.
• Use latest available pandoc release for Linux (apt), MacOS (brew) and Windows (choco) targets.
• Use official docker actions to build and push built images. Also allows to create pre-release tags so latest tag is not applied.
• Adopt GoReleaser to build binaries and create GH releases automatically when a tag is created. Allow next pre-release tags to create pre-release releases in GitHub.
• Change PackageCloud targets to use universal rpm_any tag for RPMs and any/any for DEBs.

Each commit is independent, so can be cherry-picked.

Goal is to have a 0.3.0 release using GitHub Actions workflows and GoReleaser instead of manual Makefile tasks. GoReleaser provides better release tracking, reproducibility, and metadata management.

[mrtazz]

I'm not opposed to this if overall most people agree this is an improvement. However as a bit of historical context on the current setup and why it is the way it is, I wanted to put some context to consider here. First of all my bias: I really love Makefiles 🙃 . But to the more specific points, I think the current workflow is fairly simple with few dependencies and contained in the Makefile and almost no logic in the workflow file. This means the workflow is fast and comparatively easily runnable and debuggable locally and e.g. adding a new architecture is a single line of code. Which is an important factor for me having been deep in Actions (and other CI systems) debugging rabbit holes before.

With this change the developer experience changes a lot. It's a lot harder to reason about the flows running on Actions and make (pun intended) and test changes to the workflows. There is also now logic spread and replicated across goreleaser config, makefiles, and workflow files. Which only adds to the complexity. And as far as I can tell the functionality stays the same, so there isn't really much of an improvement with the added complexity. This is not throwing shade on goreleaser, since a lot of projects use if successfully. But I also don't think that means any go project needs to use it. And I'm generally very wary of cargo culting.

GoReleaser provides better release tracking, reproducibility, and metadata management

Given that nothing fundamentally changes about the functionality I don't think this is objectively true.

That all being said, these days I don't have much time to devote to the project. So I don't think my opinion here matters too much and I'm ok to go either way here. Since @obnoxxx is currently doing most of the maintainer work here I think it's ultimately his call whether this makes daily tasks easier or more complicated.

[mikelolasagasti]

I totally get your point.

My idea with GoReleaser was to align with a more standard setup used by many other Go projects and to benefit from future improvements in GoReleaser itself without needing to adjust the Makefile every time. But you're right that with the current setup, the practical benefits compared to the existing Makefile-based release flow are fairly limited.

This PR also includes other improvements (like switching to the latest stable Go version and using the latest available pandoc) that are useful on their own. It might make sense to split those into a separate PR without the GoReleaser part (GoReleaser commit) and archive this PR/discussion for future reference if we decide to revisit GoReleaser later on.

[obnoxxx]

@mikelolasagasti wrote:

This PR also includes other improvements (like switching to the latest stable Go version and using the latest available pandoc) that are useful on their own. It might make sense to split those into a separate PR without the GoReleaser part (GoReleaser commit) and archive this PR/discussion for future reference if we decide to revisit GoReleaser later on.

Good point. I was about to request something like this per review

[obnoxxx]

@mrtazz wrote:

That all being said, these days I don't have much time to devote to the project. So I don't think my opinion here matters too much and I'm ok to go either way here. Since @obnoxxx is currently doing most of the maintainer work here I think it's ultimately his call whether this makes daily tasks easier or more complicated.

Thank you for jumping in sharing your opinion, @mrtazz !

Your opinion and input is obviously still very valuable here, also, if not primarily, for the historical context.

FWIW, @mikelolasagasti has recently been added as a project maintainer and I hope he'll take up more of the maintainer work soon. 😄

So his input here is certainly important.

We should do a new release soon-ish and if we want to modernize/improve the release workflows, it better be before that.

[mikelolasagasti]

I've created 4 different PRs to track each of the commits separately:

• https://github.com/checkmake/checkmake/pull/199
• https://github.com/checkmake/checkmake/pull/200
• https://github.com/checkmake/checkmake/pull/202
• https://github.com/checkmake/checkmake/pull/201

[mrtazz]

FWIW, @mikelolasagasti has recently been added as a project maintainer and I hope he'll take up more of the maintainer work soon. 😄

Ooh I thought I saw that flying by but didn't see him on the org members page and then wasn't sure 😅. Thanks for stepping up and contributing @mikelolasagasti!

[obnoxxx]

@mrtazz wrote:

FWIW, @mikelolasagasti has recently been added as a project maintainer and I hope he'll take up more of the maintainer work soon. 😄

Ooh I thought I saw that flying by but didn't see him on the org members page and then wasn't sure 😅. Thanks for stepping up and contributing @mikelolasagasti!

So far, @mikelolasagasti is a maintainer on the repo.

No org role (yet). -- maybe we should fix that...

[obnoxxx]

@mikelolasagasti wrote:

I've created 4 different PRs to track each of the commits separately:

* [github: Use latest stable Go release for workflows #199](https://github.com/checkmake/checkmake/pull/199)

* [github: use latest available pandoc #200](https://github.com/checkmake/checkmake/pull/200)

* [makefile: simplify PackageCloud upload targets #202](https://github.com/checkmake/checkmake/pull/202)

* [packages: migrate Docker build to docker/build-push-action #201](https://github.com/checkmake/checkmake/pull/201)

Thanks for splitting this up!

The first two (#199 and #200 ) are merged.

The other two might need a bit more discussion.

In general, I'd likr to rethink the (package and container image) publishing mechanisms since they are still pretty much tied to @mrtazz's personal accounts.

For example, I am considering to use quay.io with a checkmake org/project instead of dockerhub for container images.

I will follow up separately on these thoughts.

[eread]

@mikelolasagasti @mrtazz @obnoxxx Would it be worth doing one more release using the old release process, and then switching to a new release process can take as long as it needs?

That way folks can get the benefits of all the improvements since the last release sooner. WDYT?

[obnoxxx]

@eread wrote:

@mikelolasagasti @mrtazz @obnoxxx Would it be worth doing one more release using the old release process, and then switching to a new release process can take as long as it needs?

That way folks can get the benefits of all the improvements since the last release sooner. WDYT?

Thank you for stepping in with your opinion and this suggestion.

I think this is generally a good idea.

However, a few of the split-out PRs have already been merged.

So some details have changed, but overall, the release flow is still largely the old one.

I am in favor though of doing the nex release soon-sh with the flow as it currently is and hold off further changes to the release flow until after the release.

@mikelolasagasti - what do you think?

[eread]

@eread wrote:

@mikelolasagasti @mrtazz @obnoxxx Would it be worth doing one more release using the old release process, and then switching to a new release process can take as long as it needs? That way folks can get the benefits of all the improvements since the last release sooner. WDYT?

Thank you for stepping in with your opinion and this suggestion.

I think this is generally a good idea.

However, a few of the split-out PRs have already been merged.

So some details have changed, but overall, the release flow is still largely the old one.

I am in favor though of doing the nex release soon-sh with the flow as it currently is and hold off further changes to the release flow until after the release.

@mikelolasagasti - what do you think?

@obnoxxx So it doesn't sound like there's anything blocking a new release?

WDYT @mikelolasagasti ?