I'm declaring bankruptcy on this entire approach:
1. We can attempt to match on versions, but this will fail
when the version of `gh` installed is built from `HEAD`
or similar.
2. We can match on dates instead (since `gh --version` also includes
the date), but this is even more brittle + implies a support
contract we don't actually have (we don't actually want
to say we support random dated builds between public releases
of `gh`).
This moves us back to a simpler approach: if `gh` is present,
we use it. If `gh` is not present, we attempt to install it
with `ensure_executable!`. If the user's `gh` is present but too old,
it'll fail during attestation verification with a reasonable error,
which IMO is fine for now since this is all still in beta.
Signed-off-by: William Woodruff <william@yossarian.net>
This improves the load time of most brew commands. For an example of
one of the simplest commands this speeds up:
Without Bootsnap:
```
$ hyperfine 'git checkout master; brew help' 'git checkout optimise_requires; brew help'
Benchmark 1: git checkout master; brew help
Time (mean ± σ): 525.0 ms ± 35.8 ms [User: 229.9 ms, System: 113.1 ms]
Range (min … max): 465.3 ms … 576.6 ms 10 runs
Benchmark 2: git checkout optimise_requires; brew help
Time (mean ± σ): 383.3 ms ± 25.1 ms [User: 133.0 ms, System: 72.1 ms]
Range (min … max): 353.0 ms … 443.6 ms 10 runs
Summary
git checkout optimise_requires; brew help ran
1.37 ± 0.13 times faster than git checkout master; brew help
```
With Bootsnap:
```
$ hyperfine 'git checkout master; brew help' 'git checkout optimise_requires; brew help'
Benchmark 1: git checkout master; brew help
Time (mean ± σ): 386.0 ms ± 30.9 ms [User: 130.2 ms, System: 93.8 ms]
Range (min … max): 359.5 ms … 469.3 ms 10 runs
Benchmark 2: git checkout optimise_requires; brew help
Time (mean ± σ): 330.2 ms ± 32.4 ms [User: 93.4 ms, System: 73.0 ms]
Range (min … max): 302.9 ms … 413.9 ms 10 runs
Summary
git checkout optimise_requires; brew help ran
1.17 ± 0.15 times faster than git checkout master; brew help
```
This will mean e.g. `opoo` etc. will output to stdout and not end up
being in the stdout of `brew deps` etc.
While we're here, remove a duplicate annotation output I noticed in
`extend/kernel.rb`.
Inspired by conversation in:
https://github.com/Homebrew/homebrew-test-bot/issues/1082
Add these and correctly pass through a string to
`GitHub::Actions.puts_annotation_if_env_set`.
Also, fix some call sites to not rely on the `void` return.
We already do this for deprecations but these may make warnings
and errors from Homebrew easier to spot in GitHub Actions logs.
While we're here, cleanup other cases that should have used
`GitHub::Actions::Annotation` but didn't and provide some helpers and
tweaks there necessary for our use case here.
This should make these messages, particular warnings, more obvious to
GitHub Actions users.
There's an argument perhaps we should do this more broadly for all
warning/error messages but: this feels like a good start.
- Most usages of this were in the `pretty_duration` method, where "s"
is better described as "seconds" since we're calculating a duration.
- I also took the executive decision to do the same to "m" which refers
to "minutes".
I know that we're outside our normal deprecation cycle but: these are
totally broken with the API and it doesn't make sense to support them
only for non-core formulae.
- This `Homebrew/utils.rb` file contains one `@api public` method so it's now
included in `Style/Documentation`.
- This method not having a comment was causing the style specs to fail because
this file isn't usually failing RuboCop.
- And the test description was confusing so I improved it.
