Feature request: Update CBMC homebrew tap with every release

[zhassan-aws]

Thanks for providing CBMC's homebrew tap! This is now integrated in Kani's CI, and allows us to pin a specific CBMC version for both Ubuntu and Mac.

This might already be in the works, but is it possible to update the homebrew tap as part of the CBMC release process? It seems that the update is currently performed manually because the latest CBMC release is 5.62.0, but the tap only has up to 5.61.0.

[NlightNFotis]

Hi @zhassan-aws, the tap should now contain 5.62.0 as well.

There was a small delay this release, primarily related to #7027 causing some issues with the action running the homebrew release, which got us a bit delayed. This should not be the case moving forward, as the runner for the PR has been moved to macOS-11 as part of #7028.

Aside from this release being thrown a bit because of the runner issue, our usual policy is to perform a release every second Thursday, and then on the next day update the tap with the latest formula and the binaries.

The reason for the slight delay of the update of the tap is that we need to make sure that homebrew does have the latest release in before we can upgrade the tap, because we reuse the binaries that homebrew builds as part of a release to provide the tap binaries.

---

Without taking this release into account, and focusing on the usual process, is this something you can work with, or do you need us to have a deeper look into that?

[tedinski]

I think that's fine. Kani releases every 2 weeks on Tuesdays, so we're usually trying to turn around the Thursday release of cbmc into the Kani release 5 days later. We can do this just fine on Monday, but it'd be nice if we could reliably do it on Friday.

Is the Friday update of the tap reasonably automated? As long as we aren't at risk of regularly discovering the tap accidentally wasn't updated, I think we're good.

[NlightNFotis]

Hi @tedinski,

The release process right now is semi-automated (semi- because of branch permissions not allowing us to programmatically make changes to files, so we need one of us to submit a PR with a version change to the config file, make a tag out of the merged PR, and the rest of it is automated). There's some documentation on how it works here if that's more helpful.

The tap is more recent, and as such the infrastructure to automate this hasn't been built yet - there's some to that effect, but nothing programmatic.

This hasn't been a problem up until now, given that I have allocated a calendar event to do just that every next day after the release, and the process is a 5 minute job (just run a brew command, a shell script, and commit).

I could work towards automating this further if that's a priority for you, but be advised that problems like what happened this release wouldn't be solved by automation, because this release we were blocked by a runner failing, and this would happen in the automated case as well, with a potential side-effect being that the discovery of the failure might be delayed.

[jimgrundy]

Closing. Let's see if the process in place now works.