chore: Only do gorelease config check on CI

[langecode]

• No dry-run of goreleaser in CI pipeline
• Inline the run of govulncheck the action does not seem very stable

Fixes #15

[KimNorgaard]

@alex5517 wanted those goreleaser checks in CI. They are optional.

[langecode]

@alex5517 wanted those goreleaser checks in CI. They are optional.

Ahh, yes, I notice the release test is indeed also optional - my bad. It could just be disabled for Beagle then - but do we ever want to do a "dry-run" of goreleaser during the CI flow 🤔

[ChBLA]

@alex5517 wanted those goreleaser checks in CI. They are optional.

Ahh, yes, I notice the release test is indeed also optional - my bad. It could just be disabled for Beagle then - but do we ever want to do a "dry-run" of goreleaser during the CI flow 🤔

We could separate the goreleaser dry-run to a another workflow, i.e. prerelease or release-dryrun which only triggers on pushes to main. Then we can see whether a release would succeed before pushing a new tag, hopefully reducing "false" tags.

[alex5517]

@alex5517 wanted those goreleaser checks in CI. They are optional.

Ahh, yes, I notice the release test is indeed also optional - my bad. It could just be disabled for Beagle then - but do we ever want to do a "dry-run" of goreleaser during the CI flow 🤔

We could separate the goreleaser dry-run to a another workflow, i.e. prerelease or release-dryrun which only triggers on pushes to main. Then we can see whether a release would succeed before pushing a new tag, hopefully reducing "false" tags.

I am not a big fan of "hoping Kim waits for the CI to pass/fail on pushes to main..."

[alex5517]

One way to ensure this could perhaps be with ruleset for tags that requires workflow to pass

[langecode]

But what are the odds of the goreleaser failing if the code compiles? It is primarily plumbing around compiling the code and putting it into Brew, container image, etc. isn't it?

The resources put into running this on every single push worth it?

[alex5517]

@langecode
In regards to #15 the idea was also to verify other steps than go compile.
such as:

• Errors in Dockerfiles
• Problems during archiving
• ...

But as @ChBLA suggested it could perhaps be fine with check on push to branch with PR target to default branch and then release --snapshot ... for pushes to main with a ruleset restricting tags before it passes.

[langecode]

I'll merge this for now - then lets see what validation makes sense before doing a release.