chore(release): automate Homebrew formula updates via GoReleaser

[raphaelsamy-quantumlends]

What does this PR do?

Adds GoReleaser's native brews integration so the Homebrew tap (datadog-labs/homebrew-pack) is automatically updated on every release — eliminating the manual formula update step that currently causes the tap to lag behind GitHub releases.

Motivation

As of today, brew install datadog-labs/pack/pup installs v0.19.1 while the latest GitHub release is v0.22.0. The Homebrew formula is updated manually, which leads to version drift. GoReleaser already supports automatic Homebrew tap updates natively, making this a minimal addition to the existing release pipeline.

Additional Notes

• Maintainer action required: A HOMEBREW_TAP_GITHUB_TOKEN secret must be added to the repository settings. This should be a PAT (or fine-grained token) with write access to datadog-labs/homebrew-pack. Without this secret, the brew step will be skipped gracefully by GoReleaser.
• The brews config uses a dedicated token (separate from GITHUB_TOKEN) because the default GITHUB_TOKEN cannot push to a different repository.
• GoReleaser docs reference: Homebrew Taps

Checklist

• The code change follows the project conventions (see CONTRIBUTING.md)
• Tests have been added/updated (if applicable) — N/A, config-only change
• Documentation has been updated (if applicable)
• All CI checks pass
• Code coverage is maintained or improved — N/A, no code changes

Related Issues

Closes #108

---

🤖 Generated with Claude Code

[platinummonkey]

hey sorry we cannot do this specific change, as the github organization rules we apply must create PRs that are approved, we have a flow for automatic approvals and merges, but working on adding the support internally to support this new datadog-labs github org first

[raphaelsamy-quantumlends]

hey sorry we cannot do this specific change, as the github organization rules we apply must create PRs that are approved, we have a flow for automatic approvals and merges, but working on adding the support internally to support this new datadog-labs github org first

if possible can you elaborate? this phrasing seems to point that no opensource contribution is allowed cause only your own PR\s will get approved is that correct? just want to double check on that
if that not the case, why mine was not approved? anyway i just want to learn and/or request for the update on the README.md part of contributing to reflect this requirements

[platinummonkey]

Totally happy to explain more: It's github ruleset policies that are set at the github organization level.

goreleaser brews/homebrews_casks assumes it can directly push to main on the homebrew formula if you give it a PAT.

Where this breaks down with the rulesets:

1. We don't allow long lived PATs as a security policy so we have an STS provider to generate these. This works in our other GH organization but not this new datadog-labs organization just yet. Fix is coming for this and we can dynamically pass this to goreleaser.
2. The ruleset requires a PR to be created. Goreleaser supports this actually with a small configuration change. With homebrew_casks.repository.pull_request.enabled = true. Also note brews is deprecated on goreleaser and homebrew_casks is the latest stanza format.
3. The ruleset for signed commits will likely be enforced (this is a follow up for me), goreleaser does not support this natively, but we have a workaround commit-headless action we can use with an STS provider to sign those commits and push, the change would be to have goreleaser just make the formula as an artifact and use commit-headless to push that as a PR
4. Because the ruleset requires at least 1 PR approver it would require a person, or an automerge action we have for fine-grained specified use cases (like this). This is in a similar situation to (1) where this needs updates to work with the new github datadog-labs organization.

[soisyourface]

curious if we explore https://release-plz.dev/ for this? it is pretty awesome for rust releases.

[platinummonkey]

curious if we explore https://release-plz.dev/ for this? it is pretty awesome for rust releases.

That's neat, hadn't used it myself prior, I had mostly left the goreleaser stuff since it had rust support and pup used to be written in golang, but converted over a weekend to rust. I'll write a blog about that and how I pulled it off.