add support for credentials usage in combination with other mirroring
features. previously `HOMEBREW_DOCKER_REGISTRY_TOKEN` and
`HOMEBREW_DOCKER_REGISTRY_BASIC_AUTH_TOKEN` where only used in combination
with `HOMEBREW_ARTIFACT_DOMAIN` which affects *all* curl download strategies.
`HOMEBREW_BOTTLE_DOMAIN` is only used for bottle artifacts, whose mirror might
also require credentials.
this change removes the requirement of using `HOMEBREW_ARTIFACT_DOMAIN`.
related to #13226
- Rename use of "preinstall" to "auto update". The original "preinstall"
naming came from the fact that we used to only auto-update before
`brew install` but now that it's many commands: this is more confusing
than useful.
- Add `HOMEBREW_NO_UPDATE_REPORT_ONLY_INSTALLED` and remove
`HOMEBREW_UPDATE_REPORT_ONLY_INSTALLED`; the latter is now the default
and the prior provides an opt-out for better output, performance and
avoiding reading potentially untrusted formulae.
- Add `HOMEBREW_UPDATE_FORMULA_VERSION_CHECKS` and don't check formula
versions by default for better performance by default.
Co-authored-by: Eric Knibbe <3324775+EricFromCanada@users.noreply.github.com>
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
The `addressable` gem depends on the `public_suffix` gem but we also
need to vendor the `data` dir from `public_suffix` for `addressable`
to function correctly.
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.
