go releaser action

[dani-santos-code]

Description

This PR adds a releaser action that will create a draft release on Github and publish the library to the github registry. Notice: this has been used to publish a package and make a release already

After talking to Genevieve, we've decided not to keep a separate CHANGELOG.md file. We can either go with the body generated by go releaser or click this button to automatically tag people in contributions

I've tagged this commit a couple of times to test the plan

The plan is:

after this gets approved/merged, we'll re-tag this commit on main and trigger the action again and finally make a release!

Closes #538

example draft release: https://github.com/Shopify/kubeaudit/releases/tag/untagged-565c4cad9b0e59740674

[genevieveluyt]

Thanks for the live review and tophat! We decided to remove the changelog since the Github generated one is quite nice and get a review from our resident Github action expert Pete for any tips on the workflow config. It all works great though, the new flow is super sweet 🎉

[thepwagner]

This is dope! By building the release artifacts in an ephemeral runner, we are on our way to SLSA town 🍅🌶️ !

In terms of process, I tend to drive things more from the Create a new release

• I use the GitHub tooling to generate a changelog/release notes
• Pushing the "publish release" button is what creates the tag that starts the workflow to build the artifacts
• That version is pushed in to my build (via -X github.com/Shopify/kubeaudit/cmd.Version={{.Version}} like this build is doing). I dig how this avoids maintaining a VERSION file. I don't see the cmd.{Version,Commit,BuildDate] variables that are being embedded via -X actually being used.

It's cool because I click the button and the robots take over from there. It's not cool because sometimes things break, and you either have to undo+redo the release or fail forward quickly.

---

The other can of worms to consider is signing! By building your release artifacts in GitHub Actions, you can use the Actions worker's identity to get a short-lived signing key from fulcio!.

You may have to add sigstore/cosign-installer to the worfklow, then you can add a docker_signs section to the goreleaser configuration example

With that, the whole internet can verify the artifact they are receiving was built by Actions executing your workflow:

# Assumes cosign >= 2.0.0
$ cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity https://github.com/Shopify/hansel/.github/workflows/release.yaml@refs/tags/v0.0.9 --certificate-github-workflow-repository Shopify/hansel ghcr.io/shopify/hansel:0.0.9
Verification for ghcr.io/shopify/hansel:0.0.9 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

You can use the same technique to sign other release artifacts too! https://goreleaser.com/customization/sign/#signing-with-cosign In hansel, I use that and the .release.extra_files[] configuration to sign the blobs and the capture the certificate/signature as part of the uploaded release:

$ cosign verify-blob --certificate-oidc-issuer https://token.actions.githubusercontent.com --certificate-identity https://github.com/Shopify/hansel/.github/workflows/release.yaml@refs/tags/v0.0.9 --certificate ./hansel_0.0.9_darwin_amd64-keyless.pem --signature ./hansel_0.0.9_darwin_amd64-keyless.sig hansel
Verified OK

Sorry for all the exclamation points, I just dig this stuff. Please see all the signing stuff as optional - building the release artifacts in Actions is a massive improvement over building on developer workstations, and being able to prove the release was built in Actions brings less incremental value than building there. (currently only nerds like me will actually verify 😆)

[thepwagner]

Idea: if you track the semver tag in a comment, Dependabot should update both!
example / example PR.

I really dig it: you get the immutability of pinning a tag, without losing the visibility that the tag provides.

[dani-santos-code]

oh, neat! will add it! thank you!

[dani-santos-code]

will be addressed in a separate PR as per: #547

[thepwagner]

Question: why contents: write?

[dani-santos-code]

oh, I got it from toxiproxy: https://github.com/Shopify/toxiproxy/blob/master/.github/workflows/release.yml#L17

I assumed the release action required write to be able to create a draft release?

[dani-santos-code]

also it seems it's required? https://github.com/marketplace/actions/create-release#example

In the example above only required permissions for the action specified (which is contents: write). If you add other actions to the same workflow you should expand permissions block accordingly.

[thepwagner]

Noice: this pattern is cool!

[dani-santos-code]

this is the pattern that we had before, but were pointing to docker hub registries instead

[dani-santos-code]

I created a separate issue to address the amazing enhancements suggested in this PR, so we get unblocked when it comes to releasing since folks are waiting on us for this.

let's address this in a separate PR. thank you Pete and Genevieve for your feedback! 🙏