At the moment, `#use_homebrew_curl?` can only be true for a
`homepage` or `stable`/cask `url` with `using: :homebrew_curl`. If
the checked URL differs from these URLs, livecheck won't use brewed
curl. This limitation prevents livecheck from using brewed curl for a
`livecheck` block URL that's a string literal (not a symbol for a
`#checkable_url` like `:stable`, `:head`, `:url`). `libzip` was the
original formula referenced in the related brew issue and it meets
this criterion, so it doesn't appear to be handled by the existing
`#use_homebrew_curl?` implementation.
Additionally, the existing behavior can cause livecheck to
unnecessarily use brewed curl for a completely different website
(e.g., `cubelib`, `otf2`). For example, if the `stable` URL has
`using: :homebrew_curl` and the `livecheck` block has `url
:homepage`, livecheck will use brewed curl when checking the
`homepage`. If these are completely different domains/servers, it's
unlikely that we would need to use brewed curl when checking the
`homepage`, so this particular behavior may not be beneficial.
This commit reimplements `use_homebrew_curl?` to apply brewed curl
when the checked URL's root domain is the same as the root domain of
an aforementioned formula/cask URL with `using: :homebrew_curl`. For
example, this looser approach would allow a `livecheck` block
checking `https://www.example.com/downloads/` to use brewed curl if
the `stable` URL was `https://downloads.example.com/example.zip` with
`using: :homebrew_curl`. These could be different servers but, based
on related formulae, this looseness is necessary for the moment.
This approach aims to resolve both issues, allowing brewed curl to be
applied to a slightly broader range of URLs (i.e., not limited to
just the `#checkable_urls`) while also helping to avoid unnecessarily
applying brewed curl when it's less likely to be useful (completely
different domains). Neither approach is perfect but this one may be
more useful in the interim time.
Depending on how this looser approach works in practice, we may want
to consider returning to a stricter approach once we have something
like `using: :homebrew_curl` in `livecheck` blocks (this is
forthcoming). Being explicit in a `livecheck` block is the most
reliable approach (i.e., only use brewed curl when needed), so we
could favor that and pare down the automated approach to only what's
needed to support implicit checks (i.e., with no `livecheck` block).
Of course, it's also possible to drop the automated approach entirely
and simply require a `livecheck` block in this scenario but we can
decide on how to handle this when the time comes.
In preparation for detecting flaky tests with BuildPulse, this commit
sets up the rspec_junit_formatter gem to output JUnit XML reports of the
test suite, which is the format used by BuildPulse and various other
tooling that interprets test results.
Because the test suite uses the parallel_tests gem, this commit
incorporates some related changes to make all the parallel_tests gem and
the rspec_junit_formatter gem to cooperate with each other.
rspec_junit_formatter writes everything to a single XML file. That works
fine when there's only one process writing to the file. By default,
whatever process finishes last will write to the file and clobber the
output of all the other processes that wrote to the file. 🙈
To prevent this issue, the parallel_tests wiki recommends adding a
`.rspec_parallel` file to specify its RSpec options
(https://github.com/grosser/parallel_tests/wiki#with-rspec_junit_formatter----by-jgarber),
then the project can specify different files for each process to write
to like so:
--format RspecJunitFormatter
--out tmp/rspec<%= ENV['TEST_ENV_NUMBER'] %>.xml
However, prior to this commit, the Homebrew/brew test suite specified
its RSpec options via the command line. Unfortunately though, there's no
way (AFAICT) to set the equivalent of these options via the command
line:
--format RspecJunitFormatter
--out tmp/rspec<%= ENV['TEST_ENV_NUMBER'] %>.xml
So, we need to use a `.rspec_parallel` file to specify these options ☝️.
However, it appears that RSpec allows you to specify formatters _either_
in an options file (like `.rspec_parallel`) _or_ via command-line args.
But if you specify any formatters via command-line args, then all
formatters in the options file are ignored. (I suspect that's somehow
related to this bit of code in rspec-core:
https://github.com/rspec/rspec-core/blob/v3.10.0/lib/rspec/core/configuration_options.rb#L64.)
With that in mind, in order to have the RspecJunitFormatter configured
in `.rspec_parallel`, we need to move the other formatters into
`.rpsec_parallel` as well, instead of passing them as command-line
args. Therefore, this commit moves all the formatters into a
`.rspec_parallel` file.
> Bootsnap is a library that plugs into Ruby, with optional support
> for ActiveSupport and YAML, to optimize and cache expensive
> computations.
https://github.com/Shopify/bootsnap
For our case that translates to "repeated calls to `brew` have
reductions in the time spend `require`ing speeding up the process
boot time".
For example:
```
$ hyperfine --warmup=2 "unset HOMEBREW_BOOTSNAP; brew info wget" "export HOMEBREW_BOOTSNAP=1; brew info wget"
Benchmark #1: unset HOMEBREW_BOOTSNAP; brew info wget
Time (mean ± σ): 2.417 s ± 0.032 s [User: 659.0 ms, System: 855.5 ms]
Range (min … max): 2.382 s … 2.464 s 10 runs
Benchmark #2: export HOMEBREW_BOOTSNAP=1; brew info wget
Time (mean ± σ): 1.862 s ± 0.064 s [User: 425.3 ms, System: 566.8 ms]
Range (min … max): 1.736 s … 1.952 s 10 runs
Summary
'export HOMEBREW_BOOTSNAP=1; brew info wget' ran
1.30 ± 0.05 times faster than 'unset HOMEBREW_BOOTSNAP; brew info wget'
```
- Avoid caching RubyGems in GitHub Actions `tests.yml` to catch this in
future.
- Run `brew doctor` in GitHub Actions `tests.yml` after installing
RubyGems to catch this in future.
- Ignore relevant RubyGems (and fix outdated comments)
- Never auto-`require` RubyGems that aren't vendored.
- Update `bundler/setup.rb`.
- This was originally pinned in 1a6467eeeab8887ff404ff87b8b15d6c50c0525c
because we found that later versions surfaced over 100 new typing errors
in Tapioca's autogenerated RBI files. It seems like these are able to
be fixed now.
Having HOMEBREW_PATCHELF_RB set in the ENV,
will conditionally install patchelf.rb gem,
use patchelf.rb in the above mentioned methods.
The installed vendored gems are listed in .gitignore
to maintain a clean state.
