Extend packaging to macOS

[mikelik]

As macOS user I would like to be able to package DUNE on last 3 version of macOS which are:

macOS 11 | Big Sur
macOS 12 | Monterey
macOS 13 | Ventura

Script copied from CDT packaging on macOS gives following error on Monterey 12.6:
./generate_package.sh brew Error, unsupported OS X version

Script is available on branch: https://github.com/AntelopeIO/DUNE/tree/mikelik/macos

Originally posted by @dimas1185 in #75 (comment)

[kj4ezj]

After discussing this ticket via IM with @dimas1185, I want to share some notes on this task publicly.

AntelopeIO/leap and AntelopeIO/cdt were forked from EOSIO/eos and EOSIO/eosio.cdt respectively, but they were not forked from the latest version (intentionally). Leap, in particular, was forked from v2.0.x whereas the latest version of EOSIO was v2.2.x at the time of the fork - a difference of nearly two years (iirc)! Because of this, a number of improvements the block.one Automation team had made to the Homebrew packages were left behind, including but not limited to:

• Updating/fixing the ruby file format ^{[1, 2]}
• Supporting multiple macOS versions simultaneously
• Using CICD to verify Homebrew bottles install correctly and run on intended macOS versions before publishing them to the community
• Allowing our bottles to be installed from a local tap, for testing
• Documentation

I do not know if these improvements made it to CDT or not.

We should be able to copy/pasta most of this code as-is, and it should still work. It was one of the few contributions I worked on in my last few years at block.one that have been open-sourced. The HEAD of eos:develop and homebrew-eosio:master would be the place to look for relevant code, and I have tried to permalink it all below.

The CICD system used the EOSIO/eos/scripts/generate_bottle.sh script to package Homebrew "bottle(s)" as *.tar.gz file(s). These were attached to EOSIO draft releases (example) by an AWS Lambda. Once the EOSIO release was cut, a different lambda opened a pull request to EOSIO/homebrew-eosio (example) containing changes to the eosio.rb file that point to the new release asset(s). The CICD code (which is well documented) verified these assets could be installed from a local tap on the intended macOS versions. Finally, the pull request was merged and the changes went live to the community using Homebrew. The CICD system performed a final validation on the base branch verifying the Homebrew bottles could be installed using the public tap instead of a local tap, and an alert was generated internally if this failed.

These scripts should work as-is and only minor changes will be necessary to adapt them to run on GitHub Actions instead of Buildkite.

Here is an example of a ruby file supporting multiple versions of macOS. The file format is pretty straightforward. Note that the comments at the top of the file are important, though I do not remember why at this point.

I recommend we use our own Homebrew tap for now. This would involve creating a public AntelopeIO/homebrew-dune GitHub repository and publishing ruby files for Homebrew there. The installation instructions would be similar to this, where the customer needs to perform a "tap"...

brew tap antelopeio/dune

...then an install.

brew install dune

I understand the desire to include DUNE in the central Homebrew repository at Homebrew/homebrew-core/Formula such that customers do not have to perform a "tap," however I have the following concerns:

• Accountability to an external entity (e.g. having to get PRs to this third-party repo approved) may prevent us from responding to zero-day vulnerabilities in a timely manner.
• It may be ambiguous to community members where they should open GitHub issues if our Homebrew "bottle(s)" are broken. Do we intend to police GitHub issues in their repo?
• This may open our community to supply chain attacks, for example if Homebrew does not allow us to be set as codeowners for the Leap ruby file and an attacker convinces Homebrew to accept a pull request pointing our ruby file to malicious code.

These may be concerns the Homebrew community has already addressed, I'm not sure.