publish 3.x version of src-cli to brew

[chrispine]

Feature request:

Hey folks, would it be possible to publish the 3.x version of src-cli to brew, so it could be installed via brew install sourcegraph/src-cli/src-cli@3? since we aren’t on sourcegraph 4.x, we can no longer have people install the cli via brew

[Piszmog]

Found a page on how to setup versions. Also see this Issue from goreleaser.

[chrispine]

P0?

[courier-new]

Hey folks, looking for some input on how far to take this before calling it done. I have successfully published the formula for version 3.43.2 to Homebrew, so I could just document how to do this again somewhere, to help for version 5.0, and then call this done.

However, I was hoping we'd actually get more than this for free, based on my initial read of the blog post Randell shared. My goal was that we'd have versioned formulas published for 3.43.2 through 4.0.2 for now, and then the next time we release a new version of src-cli, we'd automatically have:

• a versioned formula for the previous release (that you could install with brew install sourcegraph/src-cli/src-cli@4.0.2)
• a new versioned formula for 4.0.3 (that you could install with brew install sourcegraph/src-cli/src-cli@4.0.3)
• an updated main formula (e.g. what you get when you brew install sourcegraph/src-cli/src-cli) that points to 4.0.3 instead of 4.0.2

But I misunderstood what the outcome of the blog post was, and that's actually not the case. If I make the changes to the goreleaser config that they recommend, we lose the ability to install via the main formula (brew install sourcegraph/src-cli/src-cli), and you can only install via a specific version (brew install sourcegraph/src-cli/src-cli@4.0.2). If I don't make the changes to the goreleaser config that they recommend, we don't get any more versions unless someone does what I did manually again. The reason is that the main formula uses a different naming convention, and goreleaser can only accommodate one or the other.

My ideal is actually still achievable, but it'll just take more work to automate. I think I could get both the versioned and main formulas updated with the following workflow:

1. Fetch the previous latest release version tag
2. Copy the current main release formula file (src-cli.rb) to a versioned formula file matching that tag (e.g. src-cli@4.0.2.rb), and update the class name to match
3. Run goreleaser like normal; this updates the main formula again
4. Remove the existing symlink for the last version and create a new one for the new version

This isn't technically necessary, though. I'd estimate an additional 0.5-1 days to get that working in the GitHub actions workflow and sufficiently tested. Should I put in the time to creating this additional automation now while it's still fresh in my mind, or should I file it away as a sustaining item, write some documentation for the manual process, and call it good?

[courier-new]

Based on our brief sync on this during our team sync today, the team is majority in favor of just doing this now while it's fresh, given it's a relatively low time cost.

[courier-new]

Opened #862 to track the follow-up release automation work, will close this one as done as the initial objective has been achieved!