feat: Publish kargo to brew

[fykaa]

closes #2514

Added the Kargo CLI to Homebrew. The formula supports macOS (Intel and ARM) and Linux (Intel and ARM) with architecture-specific binaries for version v1.0.3 currently.
Formula can be found here: https://github.com/akuity/homebrew-tap

TODO: Give Permission to access akuity/homebrew-tap.git (for creating a pull request) to github-actions[bot] (GITHUB_TOKEN)

[netlify]

✅ Deploy Preview for docs-kargo-io ready!

Name	Link
🔨 Latest commit	ea3c16e
🔍 Latest deploy log	https://app.netlify.com/sites/docs-kargo-io/deploys/6752bbe30ff20000085f4be1
😎 Deploy Preview	https://deploy-preview-3011.docs.kargo.io
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 51.20%. Comparing base (59c2db9) to head (ea3c16e).
Report is 24 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3011      +/-   ##
==========================================
+ Coverage   51.08%   51.20%   +0.11%     
==========================================
  Files         283      283              
  Lines       25373    25466      +93     
==========================================
+ Hits        12963    13041      +78     
- Misses      11712    11729      +17     
+ Partials      698      696       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[krancour]

Only very minor feedback. Overall, looks great.

[krancour]

Something to look out for. I think these are permissions WRT to the current repository. This may not be sufficient to open a PR in a different repository. We'll find out when we try this.

[hiddeco]

You are correct, for permissions to another repository you need to use a token that has access to this repository. This also means we do not have to elevate the permissions for the step here.

[fykaa]

I initially thought of 2 possible approaches to address this:

1. Move the formula file into the kargo repository so that the workflow can directly create a pull request within this same repository. This eliminates the need for cross-repository access.

2. To interact with a different repository (akuity/homebrew-tap), we'll need to generate a pat with repo scope and save it as a secretHOME_BREW_TOKEN then I can update the workflow to use it for authentication when interacting with the akuity/homebrew-tap repository

If we may want to proceed with the second approach (having separate repo for brew formula), I will remove these permissions for the step here, and use the PAT token you generate.

[krancour]

The tap absolutely needs to be a separate repo. Having played with this quite a bit recently, I'm pretty confident that things work most seamlessly when the tap repo is named <org>/homebrew-tap.

(Semi-related: akuity/homebrew-tap is not currently following the conventional layout for a tap, but it does work and we can deal with that separately later.)

Here, you can use secrets.TAP_PAT and I'll ensure that secret is configured with a PAT that can write to akuity/homebrew-tap.

[fykaa]

I couldn't find much help filtering for stable builds by checking nightly specs, but this if statement here ensures the tag doesn’t contain a -, effectively excluding alpha, RC, or other unstable releases. I also added a last statemet as a safeguard to validate the tag further. What do you think?

[hiddeco]

I think you can do something like github.event_name == 'release' && github.event.action == 'released', which would filter out prereleases. As our release candidates are typically marked as a pre-release, see e.g. https://github.com/akuity/kargo/releases/tag/v1.1.0-rc.3

Ref: https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#release

[hiddeco]

The only thing my suggestion did not take into account is @krancour's

[..] and patch releases not cut from the latest release-1.x branch

For this, I think we still need to pull off some version comparisons.

---

However, I also want to note that it's common for Homebrow to e.g. provide minor version taps. I.e., kargo.rb (latest), [email protected] (1.1.x releases), [email protected] (1.0.x releases), etc.

In the future, we should offer support for this as well. Without this, it would be impossible to update to a patch release for a previous minor version if it's released after a newer minor range.

[fykaa]

Thanks for pointing it!

I have added support for updating minor version taps.
I will see how I can update the action file to run the script with minor version tag whenever a patch version is released.

[krancour]

I have some concerns about this script. It seems a bit brittle and also isn't producing formulae that pass the default CI tests included in a new tap (which I added into that repo not long ago since they were absent).

There's been previous mention of using goreleaser to publish the CLI to our homebrew tap. I've played with it a bit and it works extremely well. I am highly in favor of pursuing that further.

The one catch is that the free/open source version of goreleaser cannot publish versioned formulae, but a pro subscription isn't very expensive and I will sort out how we can get one.