Automate updating the homebrew (os/x macos darwin) formula

[codefromthecrypt]

Title: Automate updating the homebrew (os/x macos darwin) formula

Description:
Right now, updating the os/x, macos, darwin package is something people have to remember, and sometimes do. It would be better if this was automated.

Ex.

$ brew bump-formula-pr envoy --version 1.19.1
$ brew bump-formula-pr envoy@1.18 --version 1.18.4

Points of note:
This requires permissions, so depending on how it is invoked an appropriate secret store. The permissions required are described in the brew bump-formula-pr

Currently, homebrew supports 2 envoy versions, not the entire release. At the moment, this means updating 1.19 and 1.18, but not 1.17 as it no longer exists cc @carlocab

Sometimes, and not rarely, the build changes in incompatible ways. This means someone should still monitor the PRs and address any drift problems vs assuming they would succeed

In absolute worst case, documentation telling people to update homebrew would be preferred to nothing.

Relevant Links:
https://docs.brew.sh/Formula-Cookbook
https://github.com/mislav/bump-homebrew-formula-action

[carlocab]

This might be of interest as well: https://github.com/dawidd6/action-homebrew-bump-formula

[codefromthecrypt]

I started an action to try and do this, but there are problems in the PRs maybe by next time it might work, and in that case I can raise a PR if no one does anything

1.19.1 Homebrew/homebrew-core#83921
1.18.4 Homebrew/homebrew-core#83929

[codefromthecrypt]

@carlocab it seems envoy suffers from perpetual build drift with bazel. Do you know an approach to CI so that when projects change things they know if they might break a a formula before the next release?

[codefromthecrypt]

It would be helpful if someone intimately familiar with envoy and bazel and the build can audit these also

https://github.com/Homebrew/homebrew-core/blob/master/Formula/envoy.rb
https://github.com/Homebrew/homebrew-core/blob/master/Formula/envoy@1.18.rb

We wasted a lot of people's time and also build server resources as it accidentally had a system dependency on go. It will help the whole ecosystem if this formula had no more deps than necessary and patches could be backported so that there are fewer comments in the file. cc @lizan who noticed the redundant go here

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

[codefromthecrypt]

this should be re-opened as it remains a problem. One note is that order matters, once we implement this.

Upon new minor release (ex 1.21)

1. run bump PRs for patches (ex 1.20.1, 1.19.3)
2. after the above merge, change current to latest minor

Since homebrew will maintain only 2 current versions at a time, the above flow will ensure that there is a way to have latest patch of the last 2 minors when a new one comes out. If we skip step one, that won't be possible.

[codefromthecrypt]

I've suggested homebrew drops linux support as the continuous problems and lack of ownership here is not acceptable Homebrew/discussions#2271

[codefromthecrypt]

PS to help avoid problems in the future, it would be helpful to run CI on brew install --build-from-source envoy --HEAD as this will help identify build failures before a release. For example, if there is drift in bazel or a new build dependency.

Thanks to @keith for adding the syntax to the envoy.rb

[carlocab]

You could run a regular CI job that just does brew install --HEAD envoy.