Remove BrewTestBot autocommits

[MikeMcQuaid]

Currently update-database.yml is run on a schedule which automatically commits changes to executables.txt.

Instead, we should move this logic into https://github.com/Homebrew/formulae.brew.sh and consider using the path_exec_files from the bottle manifest rather than needing to download the bottles for this.

---

Edits from @Rylan12:

Steps:

• Start pushing executables.txt to GitHub Packages
  • Push executables.txt to GitHub Packages #248
• Serve executables.txt on formulae.brew.sh
  • Add executables.txt from Homebrew/command-not-found to internal API formulae.brew.sh#1936
• Modify brew which-formula to download from formulae.brew.sh instead of the local file
  • Download executables.txt from the formulae.brew.sh API #273
  • Download new versions of executables.txt with brew update if a user has run brew which-formula before
  • Use brew which-formula --skip-update in the shell integration
  • Refactor Homebrew::API::fetch_json_api_file to be able to be used in brew which-formula, maybe use a stale_file helper as proposed in Download executables.txt from the formulae.brew.sh API #273 (comment)
• Stop auto-committing and remove executables.txt from this repository
  • Retry stop committing executables.txt to this repository #278
  • Fix working directory issue with update database workflow #282
• Remove brew which-update and all automated jobs in this repo
• Migrate brew which-formula to Homebrew/brew
• Convert executables.txt to a JSON file
• Keep track of executables during bottle creation, and store in OCI manifest file
• Update executables.txt in formulae.brew.sh by downloading the OCI manifest files and pulling the executable list from there

[Rylan12]

Convert executables.txt to a JSON file

I've looked into this a little bit to compare file size and loading time between a JSON file and the current executables.txt approach:

Options

1. The current executables.txt approach:

   a2ps(4.15.7):a2ps a2ps-lpr-wrapper card composeglyphs fixps lp2 ogonkify pdiff
   ...
   

2. A JSON Formula -> Executables approach:

   {
     "a2ps": ["a2ps", "a2ps-lpr-wrapper", "card", "composeglyphs", "fixps", "lp2", "ogonkify", "pdiff"],
     ...
   }

3. A JSON Binary -> Formula approach:

   {
     "0alias": ["zero-install"],
     ...
     "Assistant": ["qt", "qt@5"],
     ...
   }

Note: I didn't include formula versions in the two JSON options because once this information comes from bottle creation, we won't need to keep track of the formula versions

File Sizes

Option	Uncompressed Size	Compressed Size
executables.txt	373 kB	138 kB
JSON Formula -> Executable	391 kB	119 kB
JSON Executable -> Formula	535 kB	131 kB

brew which-formula benchmarks

I randomly chose three test executables to lookup: benthos, gdaladdo, and jsonnet. Here are the results from a benchmark with hyperfine --warmup 5 'brew which-formula NAME':

Option	benthos	gdaladdo	jsonnet
executables.txt	460.5 ms	466.0 ms	466.5 ms
JSON Formula -> Executable	473.6 ms	472.5 ms	471.8 ms
JSON Executable -> Formula	474.0 ms	473.8 ms	472.9 ms

Results

The JSON Formula -> Executable is the smallest when compressed, indicating that it will likely be the fastest to download from the API. It is slightly larger than executables.txt when uncompressed, but it's less than a 20 kB difference.

In terms of the brew which-formula benchmarking, both JSON options seem to take about the same amount of time, but 5–15 ms longer than executables.txt.

So, if we go the JSON approach, the Formula -> Executable option is best since it's the smallest file size. However, it's not clear whether that's better than the executables.txt approach.

My impulse is to use the JSON approach because it makes the code simpler—we can just work with the JSON library and regular Ruby hashes. Also, I think it may play nicer with the existing JSON API infrastructure we have in Homebrew/brew.

However, I'm open to thoughts on whether the 15 ms slowdown is worth keeping executables.txt.

[Bo98]

15ms is probably fine, though overall we would need to take care not to regress #108 even further and make it so typing invalid commands in your terminal starts triggering network requests.

Ideally this information would be cached by the most recent brew update and brew which-formula just uses that (and do nothing if brew update has never been run).

Longer term, it would probably ideal to port the commands in this repo to bash. So the answer to format might be whatever would be easiest to read from bash.

Parts of what I've mentioned here may also require merging this into Homebrew/brew at the same time.

[Rylan12]

15ms is probably fine, though overall we would need to take care not to regress #108 even further and make it so typing invalid commands in your terminal starts triggering network requests.

Ideally this information would be cached by the most recent brew update and brew which-formula just uses that (and do nothing if brew update has never been run).

Calling brew which-formula directly is probably fine to download (using the usual auto-update timeout), but yeah, we probably should rely on brew update for the shell integrations.

Longer term, it would probably ideal to port the commands in this repo to bash. So the answer to format might be whatever would be easiest to read from bash.

Good point. My impulse is that executables.txt feels easier in bash, but that's a gut feeling and is unsubstantiated

[Bo98]

Calling brew which-formula directly is probably fine to download (using the usual auto-update timeout)

The handler calls brew which-formula internally:

homebrew-command-not-found/handler.sh

Line 42 in 0328862

txt="$(brew which-formula --explain "${cmd}" 2>/dev/null)"

[MikeMcQuaid]

Good point. My impulse is that executables.txt feels easier in bash, but that's a gut feeling and is unsubstantiated

It probably is unless you reach for jq.

15ms is probably fine, though overall we would need to take care not to regress #108 even further and make it so typing invalid commands in your terminal starts triggering network requests.

I think it's fine.

I think we should avoid network requests but it's more important to ensure we can get this repo merged into Homebrew/brew and the current auto-commit workflow is removed than make sure we're watertight on network edge cases.

[XuehaiPan]

• Refactor Homebrew::API::fetch_json_api_file to be able to be used in brew which-formula, maybe use a stale_file helper as proposed in Download executables.txt from the formulae.brew.sh API #273 (comment)

PS: The JSON API may not be downloaded if HOMEBREW_NO_INSTALL_FROM_API is set.

$ brew update --verbose
Checking if we need to fetch /home/linuxbrew/.linuxbrew/Homebrew...
Checking if we need to fetch /home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew
-command-not-found...
==> Updating Homebrew...
Fetching /home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew-command-not-found..
.
Checking if we need to fetch /home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/homebrew/homebrew
-core...
HOMEBREW_NO_INSTALL_FROM_API set: skipping API JSON downloads.
Already up-to-date.

[p-linnane]

PS: The JSON API may not be downloaded if HOMEBREW_NO_INSTALL_FROM_API is set.

We ran into an issue when running brew tests without a local copy of the API JSON files. Starting to wonder if we should just grab them when updating even if HOMEBREW_NO_INSTALL_FROM_API is set, since more things are leaning on them as time goes by.

[MikeMcQuaid]

@p-linnane It'd seem sensible to me that that's just overridden when running brew tests, yeh.