This provides an extra field to the GitHub Packages manifest about the
executable files in `bin` or `sbin` directories of the bottle.
It also provides an extra GitHub Packages JSON file with the list of all
files.
This would allow us (post a large rebottling effort) to start providing
this information in the Homebrew JSON API.
It also provides a much nicer information source for e.g.
homebrew-command-not-found that doesn't involve downloading actual
bottles.
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
- Not only `false` to `true` but `true` to `strict`.
- Only humans every run this, but our goal is to increase the
typechecking in our files to get to `strict` everywhere so
let's make that easy to remember to do.
- This inconsistency of "author", "committer", "coauthorship", that is, only "coauthor" ending in "ship", has annoyed me ever since I wrote it. It has finally sufficiently annoyed me to fix it.
- This was broken (I did have a commit SHA for the breakage but I can't find it now) since `from` and `args.from` are different variables (one can be nil, the other has a default value).
- So it was reporting very high counts because, despite the message, the `from` restriction was not being passed to `count_repo_commits`.
- 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
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.
- 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
It would be helpful for taps to document how they are to be used with `Brewfile`.
Adding documentation for formulae installation to the generated tap readme would help ensure that new taps have this helpful documentation in their repos from the start.
There are two big changes here. Both have to do with how we want
to load casks in different scenarios. One also is related to formulae.
1. Prevent loading casks & formulae outside of taps for specific commands.
There are certain commands like `bump`, `bump-*-pr`, `livecheck` and `audit`
where it really makes no sense to try and run things if the specified formulae
or cask is not in a tap. A new `#to_formulae_and_casks_with_taps` method was
added to the `CLI::NamedArgs` class to allow us to easily grab and validate
formulae and casks from named arguments.
2. Always load the source file path when loading casks with the path loader.
There was an edge case where all JSON cask files were being loaded without
setting the source file path because most of the work was handed off to the
API loader where that normally would make more sense. Now we set that when
calling the API loader which solves the problem. This improves the user
experience of people using the `--cache` and `fetch` commands in certain
edge cases. Hopefully it makes the user experience a bit more consistent.
A regression test was added for this point.
This avoids can avoid UID/EUID related issues with Ruby scripts passed
over `stdin` clashing with Ruby security features.
It's also just a bit nicer to have Ruby scripts in files instead.
While we're here:
- refactor some shared logic into a new `setup-gem-home-bundle-gemfile`
function in `ruby.sh`
- do some general cleanup of `lock.sh`
- prioritise `flock` over `python` in `lock.sh`
