Automate release with goreleaser and GitHub Actions

[karuppiah7890]

• Update build command in RELEASE.md
• Adds goreleaser config yaml
• Ignore goreleaser's dist directory which is used as the build / distribution directory
• Adds GitHub Action workflow config yaml for automatic release using goreleaser on push of git tag

Fixes #37

Should I also update the RELEASE.md with the information about goreleaser and GitHub Actions workflow for automatic release once the repo has a git tag for a given version? I think step 3 and 4 would need some changes - https://github.com/kubernetes-sigs/depstat/blob/main/RELEASE.md to mention that release (building and creating GitHub release) is automated but yeah, the owner can change the changelog for the GitHub release if it's needed

You can look at a sample of the GitHub Actions workflow here - https://github.com/karuppiah7890/depstat/runs/3424475399?check_suite_focus=true

and a sample release here - https://github.com/karuppiah7890/depstat/releases . Particularly - https://github.com/karuppiah7890/depstat/releases/tag/v0.7.0-rc.1 , a dummy RC release

Let me know if we want to split the single commit automate release process using goreleaser and github actions into two commits like - add goreleaser config yaml for automated release and add github action workflow config yaml for automated release using goreleaser

Some things to note

• I'm using most of the defaults of goreleaser config yaml, for example things like snapshot config. We can remove it if we think we never need it
  • changelog includes commits, due to the changelog config and feature of goreleaser
• I'm using go v1.16 as that's what is being used in go.mod and also in the existing GitHub Action workflow. But we can change it if needed to v1.17 as it's already out https://golang.org/dl/
• The build targets are - OSes - Linux, MacOS, Windows. Architectures - arm64 (Not on Windows), x86_64, i386 (Not on Mac) . This comes by default and if we use go v1.17, we will get Windows arm64 too as go v1.17 supports it. Let me know if these targets are good / if they are too much and we can reduce it

Since we have goreleaser config now, with this we can also have a install.sh script with the help of godownloader for automated install. Let me know if we want to add that too, in this PR or separate PR with separate issue for installer script

Also, do we want to publish Docker images? Something to discuss, in case we want to use it in containers. I noticed mention of prow jobs, those run in containers? We can discuss that too in a separate issue or here. GoReleaser supports releasing Docker images it seems

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: karuppiah7890
To complete the pull request process, please assign navidshaikh after the PR has been reviewed.
You can assign the PR to them by writing /assign @navidshaikh in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[RinkiyaKeDad]

Thank you so much for the PR @karuppiah7890!

Adds GitHub Action workflow config yaml for automatic release using goreleaser on push of git tag

How would this work? We maintain only a single main branch, would we have to cut separate branches for releases after this?

Should I also update the RELEASE.md

Yes, please. I'm not familiar with goreleaser so if we have the entire process noted step by step in the RELEASE.md it would be of great help.

Let me know if we want to split the single commit

The /label tide/merge-method-squash label should squash all commits in this PR so no need to worry about that.

But we can change it if needed to v1.17

Let's stick to 1.16 right now since 1.17 changes how go mod graph works, which basically breaks depstat.

Also, do we want to publish Docker images?

We don't have a use case for that (as of now 🙂) so I guess we can skip it. In the prow job we simply install depstat using go install.

@kubernetes-sigs/depstat-admins can someone please help review this, I've little knowledge about release best practices.

/label tide/merge-method-squash

[karuppiah7890]

How would this work? We maintain only a single main branch, would we have to cut separate branches for releases after this?

No, there's no need to cut separate release branch, we just have to push a git tag which we are already doing. But yeah, I can put extra condition that only git tags on main branch can be released, currently I think it will release for any git tag on any branch, but yeah normally I don't think we will be having semantic version tags on other branches

Yes, please. I'm not familiar with goreleaser so if we have the entire process noted step by step in the RELEASE.md it would be of great help.

There's no process really per se, haha. goreleaser does the whole job of building all the binaries and creating checksums file and also creating a GitHub release and uploading the binaries and the checksums file. goreleaser also adds a list of git commits from last release till current release as changelog in the GitHub release. All of this happens the moment one pushes a git tag, which triggers a GitHub Actions workflow that runs goreleaser which takes care of everything like I just said

The /label tide/merge-method-squash label should squash all commits in this PR so no need to worry about that.

The PR already has a single commit only for goreleaser stuff, and another for RELEASE.md file update. I was asking about splitting one of the two commits into two leading to three commits in this PR. I was not asking about squashing the commits. But yeah, I guess we can squash it

Let's stick to 1.16 right now since 1.17 changes how go mod graph works, which basically breaks depstat.

Ah okay, cool

We don't have a use case for that (as of now 🙂) so I guess we can skip it. In the prow job we simply install depstat using go install.

Cool ! and who uses the released binaries? human users? Since prow uses go install and uses latest version. Also I currently see only MacOS binaries in releases

[RinkiyaKeDad]

But yeah, I can put extra condition that only git tags on main branch can be released

Yup that sounds good, thanks!

All of this happens the moment one pushes a git tag

Could you please add a line about the command to be used for this in RELEASE.md?

and who uses the released binaries? human users?

Not sure if we have any users 😅 but yes we just release the binaries in case someone wants to use them (maybe in the future :P). I've been building the binaries on MacOS using go build and dropping them manually for each release and that's why there are only MacOS binaries :)

[karuppiah7890]

/hold

Holding till I make changes to the PR based on the comments

[karuppiah7890]

/remove-hold

[karuppiah7890]

Made the changes as mentioned 👍

[karuppiah7890]

Should we probably open up this PR when it's needed? I don't think folks have bandwidth to look at this PR now. Also, it's not urgent I believe. So we could close it for now

[RinkiyaKeDad]

Let's leave it open, no? I'll have to cut a release soon (hopefully this month) and maybe we can merge and test this out then, WDYT? 🙂

[karuppiah7890]

Okay! 👍

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[karuppiah7890]

Any thoughts on what we should do about this PR? 😅 Should I remove the life cycle labels?

[RinkiyaKeDad]

I guess so, but we wouldn't be doing any releases soon since we're still waiting on a word from the go team on this.

[RinkiyaKeDad]

/remove-lifecycle rotten

[developer-guy]

kindly ping @karuppiah7890 @RinkiyaKeDad nice works, everything looks good! 🥳🚀

But I've got a bunch of questions. 🙋🏻‍♂️

• Do we want to build and push container images of depstat? If so, we can manage them through GoReleaser as well.

• Should we add multi-arch support to depstat?

• Should we consider adding some stuff like a sign, SBOM, etc to make more secure releases? (All of them are now supported in GoReleaser, here is the example repository.)

• Should we consider reproducibility in depstat binary? Again, if so, we can achieve this by adapting a bunch of additional GoReleaser config and ldflags.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.