Update Github Actions in CI and check go fmt

[selfhoster1312]

This PR:

• removes unused (at least for now) CI workflows
• updates Github Actions used in the CI, and the golangci-lint version
• checks that go fmt ./... is applied on future PRs
• only tries to upload build artifacts if testing is successful
• runs builds for different targets in parallel (CI takes 1 minute less from ~3m40s to ~2m40s)

Review welcome :)

[poVoq]

I am sadly not familiar with Github actions, so I can't comment much on this.

(Once we migrate to Codeberg it should work with Forgejo actions though, or I could look into setting up a Woodpecker runner)

[selfhoster1312]

I rebased on master (due to the docs update #1 which stopped CI running on docs, producing a conflict).

If someone would like to review, feel free to go ahead. @poVoq even if you don't know anything about Github actions, you can read commit by commit it's mostly straightforward changes, except for b6c0860 which has a little too much magic because the .golangci-lint syntax changed a lot in the past years.

[poVoq]

Well, I looked at it, but I really don't feel qualified to comment on this. But it's not like much can break that isn't fixable afterwards, so lets just try?

[Jaykul]

I don't like removing the container build, because I, for one, only use this from container images.
Obviously I can keep maintaining my own, but why are we taking it out?

[selfhoster1312]

I don't like removing the container build, because I, for one, only use this from container images.

That's a very good point! I removed it because i'm not very familiar with registries and it was using API keys i don't have at hand. Since you seem more experienced with this, can i just remove the Docker Hub part and leave the GHCR in CI and it will automatically use our GITHUB_TOKEN to publish test images?

We don't really have a packaging policy yet or registered package maintainers. Would you like to maintain the Docker side of things @Jaykul ?

[Jaykul]

Yes -- taking out docker is what I did in my fork -- I can push that file if you like.

What do you think about ARM64? I turned off the ARM container build because it takes 15 minutes almost, on QEMU, and that just made me impatient. I don't know if anyone's actually using that ... but I suppose they can ask, if they want it...

[poVoq]

So we merge this and @Jaykul could make another PR with the correct container building?

I think that ARM64 would be nice to support for running it on a RasberryPI or so.

[selfhoster1312]

Yes -- taking out docker is what I did in my fork -- I can push that file if you like.

Yes please! Just open a new PR :)

What do you think about ARM64? I turned off the ARM container build because it takes 15 minutes almost, on QEMU, and that just made me impatient. I don't know if anyone's actually using that ... but I suppose they can ask, if they want it...

Wow that's slow! To be fair, if we introduce proper integration tests as in #4 CI is always going to be slow. That's a tradeoff we should discuss. I personally believe pushing containers on PRs is of limited use when PRs are getting properly and timely reviewed/merged, and what would be important would be to have containers published on releases. What do you think? I also think it'd still be useful to have docs on how to generate containers for other architectures.

[selfhoster1312]

@Jaykul @poVoq if this PR looks ok to you feel free to press the "rebase and merge" button :)