If set, this will update the Homebrew API formula or cask data even if
`HOMEBREW_NO_AUTO_UPDATE` is set.
This is useful in cases where you want to update the cached API data but
don't want to update Homebrew itself.
Co-authored-by: Bo Anderson <mail@boanderson.me>
Formulae, casks, and resources have a `#livecheckable?` method that
indicates whether they contain a `livecheck` block. This is intended
to be read as "has a livecheckable?", not "is livecheckable?" (as
livecheck can find versions for some packages/resources without a
`livecheck` block). Unfortunately, correct understanding of this
method's behavior [outside of documentation] relies on historical
knowledge that few people possess, so this is often confusing to
anyone who hasn't been working on livecheck since 2020.
In the olden days, a "livecheckable" was a Ruby file containing a
`livecheck` block (originally a hash) with a filename that
corresponded to a related formula. The `livecheck` blocks in
livecheckable files were integrated into their respective formulae in
August 2020, so [first-party] livecheckables ceased to exist at that
time. From that point forward, we simply referred to these as
`livecheck` blocks.
With that in mind, this clarifies the situation by replacing
"livecheckable" language. This includes renaming `#livecheckable?` to
`#livecheck_defined?`, replacing usage of "livecheckable" as a noun
with "`livecheck` block", replacing "livecheckable" as a boolean with
"livecheck_defined", and replacing incorrect usage of "livecheckable"
as an adjective with "checkable".
Our autobump workflow sets the author and committer to the user who
triggered the workflow, defaulting to @BrewTestBot for scheduled runs.
This can be confusing for maintainers when GitHub shows up as
"Unverified" because the commit is signed with @BrewTestBot's key.[^1]
Let's fix that by configuring our autobump workflow to always commit as
@BrewTestBot, so that the committer matches the GPG signature. To do
that, we need to add support for setting `GIT_COMMITTER_NAME` and
`GIT_COMMITTER_EMAIL`.
[^1]: See, for example, Homebrew/homebrew-core#197234.
My experience recently playing around with our locking behaviour is
that, while mostly seamless and not seen by users, it's leaks
implementation details a bit too heavily.
As a result, the following improvements are in this commit:
- Ensure that, whenever possible, we tell the user the actual command
that is holding a given lock instead of the lock name (an internal
implementation detail)
- Make the locking error output a little more consistent and user
friendly
- Add a `DownloadLock` class to simplify locking downloads
- Add a `HOMEBREW_LOCK_CONTEXT` variable to allow adding additional
context for logging error messages
- Lock paths and leave deciding how this translates to lock names up
to the locking code itself
- Lock the Cellar/Caskroom paths explicitly rather than implicitly
Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
Take 2 of https://github.com/Homebrew/brew/pull/17692 but with:
- provide and document `HOMEBREW_NO_VERIFY_ATTESTATIONS`
- don't try to run unless there's GitHub credentials
- don't try to run unless `gh` is installed
- don't try to run in CI
While we're here:
- split out a `Homebrew::EnvConfig.devcmdrun?` helper method
- add some missing `Homebrew::EnvConfig.github_api_token` presence
checks
Add `brew tab`, a new command to edit tab information, as previously
discussed in https://github.com/Homebrew/brew/pull/17125#issuecomment-2068473483.
Currently, this supports marking or unmarking formulae as installed on
request.
Sample usage:
$ brew tab --installed-on-request curl
==> curl is now marked as installed on request.
$ brew autoremove --dry-run
[no output]
$ brew tab --no-installed-on-request curl
==> curl is now marked as not installed on request.
$ brew autoremove --dry-run
==> Would autoremove 2 unneeded formulae:
curl
rtmpdump
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
