This is primarily intended to resolve the `uninitialized constant
Utils::Backtrace` error in `formula_versions.rb:60` but I expanded it
to try to cover all existing usage of `Utils::Backtrace`.
I've followed the existing pattern, where `utils/backtrace` is
required in the context of where it's used. Many of these cases use
`Backtrace` in a conditional manner, so I've tried to ensure that the
`require` follows suit.
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 widens the beta to include people with developer mode enabled,
as well as those with HOMEBREW_DEVELOPER set in their environment.
Signed-off-by: William Woodruff <william@yossarian.net>
- Remove use of (unused) `Cachable` module.
- Pass whether we're bottling to determine whether to create
reproducible SBOM or not. A reproducible SBOM omits the time and
compiler.
- Remove bottle information when bottling: we cannot know what e.g.
the checksum (and, with GitHub Packages, therefore also the download
location) will be before we've created the tarball contents.
- Always write a bottle on installation (unless we're bottling) to
provide new bottle information or freshen the existing one with the
information we stripped out for reproducibility e.g. the time and
compiler.
- Don't need to handle a `nil` `@source_modified_time` as it's always
set.
Fixes#17281
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.
- write a schema when installing formulae (if not already present)
- cache the schema on disk rather than downloading it every time
- make more methods/attributes `private`
- allow validation to be optional, only enable for Homebrew developers
at installation time
- use the tab for more, correct information
- ensure that dependencies/bottles are written correctly
- use new SBOM 3 schema URL
- improve test coverage
Adds the basic attestation verification APIs, as well
as a pre-pour check against `HOMEBREW_VERIFY_ATTESTATIONS`
that verifies the attestation (or backfill as necessary)
for bottles from homebrew-core.
Signed-off-by: William Woodruff <william@yossarian.net>
We already had `HOMEBREW_FORBIDDEN_LICENSES` but this commit adds
`HOMEBREW_FORBIDDEN_CASKS`, `HOMEBREW_FORBIDDEN_FORMULAE` and
`HOMEBREW_FORBIDDEN_TAPS` for also forbidding those.
Relatedly, add `HOMEBREW_FORBIDDEN_OWNER` and
`HOMEBREW_FORBIDDEN_OWNER_CONTACT` to allow customising these
messages.
There were no existing tests for `HOMEBREW_FORBIDDEN_LICENSES` so have
added more tests for all of these checks.
Co-authored-by: Bo Anderson <mail@boanderson.me>
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.
We have plans to add analytics for commands and `brew test-bot`
This requires a certain amount of refactoring which I've done here.
There was also a bunch of legacy `*_influx_?` usage from when we used
both InfluxDB and Google Analytics that made sense to clean up and
excessive indirection.
Let's start storing `revision` and `pkg_version` for tab runtime
dependencies and use them when available.
When the `revision` is not available, use a conservative approach to
deciding whether dependencies need to be upgrade.
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
Ever since we started using this at runtime it's been polluting
the backtrace output. This makes it harder to debug errors and
increases the amount of info users have to paste into the box
when filing an issue.
This is a very direct approach. Essentially, we strip out
everything related to the `sorbet-runtime` gem whenever the top
line in the backtrace is unrelated to sorbet-runtime.
The hope is that this will allow errors related to sorbet to
be diagnosed easily while also reducing the backtrace size
for all other types of errors.
Sometimes it is useful to see the full backtrace though.
For those cases, we include the full backtrace when
`--verbose` is passed in and print a warning that the
Sorbet lines have been removed from the backtrace the
first time they are removed.
Note: This requires gems to be set up so that the call to
`Gem.paths.home` works correctly. For that reason, it must
be included after `utils/gems` which is included in
`standalone/load_path` already.
Download the bottle manifests for the potential formulae we are going to
upgrade and, if they are have all their `runtime_dependencies` versions
currently met, don't try to download the bottle or upgrade the formula.
When we're installing a formula from a bottle, we currently always
upgrade all dependencies in the dependency tree to be safe.
However, if we're installing a bottle and the `runtime_dependencies`
within that bottle's tab all have older or equal versions to those
already installed: we do not need to upgrade these dependencies.
This should help a lot of upgrading a lot of the time, at least for
users using bottles (which is the huge majority).
The only downside or other noticeable change is that this requires us
to download or attempt to download the bottle tab before we compute
the dependencies at installation time.
Co-authored-by: Kevin <apainintheneck@gmail.com>
- warn if running `brew postinstall` explicitly and there's no
`post_install` defined in the formula
- add a `post_install` alias for `brew postinstall` to make life
easier for those jumping between `postinstall` and `post_install` in
e.g. Homebrew development
- refactor `post_install` formula path logic into a new method for
improved readability
- handle the JSON API `post_install` formula path case
