At the moment, Microsoft Office and related casks fail audit due to
failure to fetch a product homepage from the main Microsoft site
(https://www.microsoft.com/) served by Akamai CDN.
The failure is severe and weird: no status code is received as the
connection is reset.
The analysis revealed the issue is linked to `User-Agent` and
`Accept-Language` headers parsing. Homebrew uses involved user agent
strings and has language hardcoded as `en`.
The simplest workaround is to use a simple user agent string when checking
homepage availability if the cask is in an audit exceptions list.
Merging this would fix Microsoft Office updates (including
https://github.com/Homebrew/homebrew-cask/pull/162671)
The `#audit_stable_version` check was previously part of
`#audit_revision_and_version_scheme` and duplicates some of the
logic to identify previous version information. To avoid the
duplication, this extracts the logic into a `#committed_version_info`
method that can be called in both audits. The method stores the
information in instance variables, so we don't repeat the collection
process if it has already run.
The "stable version should not decrease" formula audit currently
prevents us from being able to create bottles when downgrading a
formula version. We previously worked around this by bumping
`version_scheme` but this wasn't an intended use case and we now
avoid using it for this purpose.
We can handle simple formula downgrades by reverting changes in a
syntax-only PR but that isn't sufficient when we need new bottles
(i.e., if additional changes have been made to the formula in the
interim time). In the latter case, the only available solution may be
to revert all changes made after the previous version using a
syntax-only PR and then create another PR to reintroduce the other
changes and create new bottles.
To avoid the aforementioned approach, this splits the stable version
audit into a separate method, so we can use `brew audit
--except=stable_version` to selectively skip it.
- As discussed in
https://github.com/Homebrew/brew/pull/16337#issuecomment-1855668516,
then we won't have the chicken/egg problem of fixing cops for syntax
that's unsupported on Ruby 2.6 _before_ we set the TargetRubyVersion
to 3.1, but if we set it too early then all the taps will fail.
If an installed cask is invalid on attempting an untap: it will
prevent untapping that cask.
Fix this in two ways: one more specific to `untap` and one more
generally to other commands too:
- specific: only read the actual formulae/casks from the tap we're
untapping instead of all of those that are installed
- general: rescue more exceptions in `Cask::Caskroom.casks` (like we
already do for `Formula.installed`
This was not returning the full name correctly for e.g. anything in
Homebrew/homebrew-fonts.
While we're here, fix up a few other places where `tap.core_cask_tap?`
can be used more appropriately.
The idea here is that it should be expected that `brew upgrade` will
not upgrade pinned packages but will attempt to upgrade everything else.
For that reason, it will only show a warning about pinned packages
in that case.
If, on the other hand, you pass the name of a pinned package explicitly
to the upgrade command, like in `brew upgrade PINNED`, we want to show
an error since we cannot upgrade that package until it gets unpinned.
