Publishing cli app binaries with project releases

[rsjethani]

Requirements:

Automatic CI workflow to build and publish at least Linux and Mac OS binaries whenever we create a new project release

Some options I see:

• https://github.com/slsa-framework/slsa-github-generator
• https://goreleaser.com/

Lets collect knowledge on this subject and decide on best approach in this discussion

[rsjethani]

cc @StefMa @zadjadr @chb-ioki

[StefMa]

I don't have a strong opinion here, except of the fact that I have literally no expirience with the two mentioned tools. I just ask myself if we even need a third party "releaser" in the beginning? Why not start simple and simply create a new GH Action workflow that: * get triggered by an git tag push (vX.Y.Z) * generates the cli client * create a draft release and attach the cli client I never did the last one yet, but I guess this should be pretty straightforward since we can use the github scripint stuff within gh actions... https://github.com/actions/github-script

…

On Fri, Jul 28, 2023, 4:12 PM Ravi Shekhar Jethani ***@***.***> wrote: cc @StefMa <https://github.com/StefMa> @zadjadr <https://github.com/zadjadr> — Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOBQ62PPOKBKI7YEHTLWL3XSPCDJANCNFSM6AAAAAA23R2CZI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zadjadr]

I agree, it's better to keep it simple at first and add a releaser if really needed

[rsjethani]

IMO rolling your own workflow based on https://github.com/actions/github-script will require more or less same amount of work as say using https://goreleaser.com/ or https://github.com/marketplace/actions/go-release-binaries. The latter approach has the advantage of being battle tested and in use in many many go projects. So I am going to explore latter approach.