We have a `HOMEBREW_MACOS_NEWEST_UNSUPPORTED` environment variable
and this is used in `MacOSVersion` to determine prerelease versions
but we don't have a way of easily determining the newest supported
macOS version.
`bump-cask-pr` contains logic that assumes the first key/value in
`MacOSVersion::SYMBOLS` is the newest macOS version but it recently
became clear that this is a prerelease version between WWDC and the
subsequent macOS release. Similarly, `dev-cmd/generate-cask-api.rb`
tries to compute the newest stable macOS version as
`HOMEBREW_MACOS_NEWEST_UNSUPPORTED.to_i - 1` and this will fail
if/when we update that variable to `"26"`, as the macOS version
before 26 is 15, not 25.
This adds a `HOMEBREW_MACOS_NEWEST_SUPPORTED` environment variable,
so we have a straightforward way of quickly identifying the newest
supported macOS version without having to make potentially unreliable
assumptions or do computations to identify the latest non-prerelease
`MacOSVersion` value. This also updates the two aforementioned areas
to use this environment variable to produce the newest stable macOS
version symbol in a more reliable way.
The flag used to work well, but at some point started to run more and
more git actions. We use this to update formula and casks in other
homebrew taps, and it works well except for this issue.
`Homebrew::SimulateSystem.current_os` may be returning the host OS or
a simulated OS and we can't be sure which in this context. At the
moment, this is expected to be the host OS but that may change in the
future. It shouldn't matter on a technical level but using "host" in
these variable names may lead to confusion.
This replaces "host" in names with "current", as it more accurately
describes the information.
This extracts the logic for generating the `system_options` array in
the `replace_version_and_checksum` method into a separate
`generate_system_options` method. This logic is becoming more complex
(after recent changes) and manually testing it is a pain, so this
change is intended to allow us to add tests. The tests added here
provide 100% coverage for the method.
This reworks the `SimulateSystem` args in the `bump-cask-pr`
`replace_version_and_checksum` method to respect `depends_on arch`
values in casks. That is to say, we shouldn't simulate Intel for a
cask using `depends_on arch: :arm64` and we shouldn't simulate ARM if
the cask uses `depends_on arch: :x86_64`.
In the process, this refactors how we collect/combine OS/arch values.
To make this approach work predictably, I removed the logic that
omits OS values matching the host OS (as `SimulateSystem` already
handles this). The `[{ os:, arch: }]` hash format only made sense when
we were omitting values, so this returns to the previous
`[[os, arch]]` array format (to align with the
`OnSystem::ALL_OS_ARCH_COMBINATIONS` array format).
The `replace_version_and_checksum` method handles a `CaskInvalidError`
when loading a cask (handling casks that aren't valid on Linux) but
we can sometimes still encounter an error when bumping a cask with
on_system blocks. For example, bumping `displaylink` will produce a
`Cask 'displaylink' is unreadable: undefined method 'csv' for nil`
error when `SimulateSystem` runs as Linux, as the cask interpolates
`version.csv.first` in a `license` string but `version` isn't set on
Linux.
This adds `Cask::CaskUnreadableError` to the `rescue` arguments,
which accounts for this particular situation (allowing `displaylink`
to be bumped like before).
`bump-cask-pr` was recently updated to add Linux support but the
change to the `replace_version_and_checksum` logic has broken the
command for casks that have on_system blocks that reference specific
macOS versions (e.g., `on_monterey :or_newer` in `logi-options+`).
The previous logic only simulated the arch, so the `current_os` value
on macOS was a specific version like `:sequoia`. The current logic
uses generic `:macos` values, which work for `on_macos` blocks but
don't work for blocks like `on_sequoia`, etc. This leads to an
`undefined method 'latest?' for nil` error, as `old_cask.version` is
`nil` in this scenario (i.e., none of the on_system blocks apply to
`:macos`, so `version` is never set).
This updates the method to only specify the OS in `system_options` if
the value doesn't align with the host (e.g., `:linux` on macOS),
which restores the previous behavior.
This also replaces `:macos` values with the newest macOS version
(e.g., `:sequoia`), so that `bump-cask-pr` on Linux can update casks
with on_system blocks that reference specific macOS versions. A
generic `:macos` value doesn't work with those on_system blocks, so
`version` is never called on Linux in that scenario but it works as
expected if we use the newest macOS value instead. This may not be
perfect but it brings `bump-cask-pr` a little closer to parity with
macOS on Linux.
Lastly, this skips `system_options` values where `old_cask` has no
version, as this means the cask doesn't apply to that OS/arch. We've
been seeing a related error on homebrew/cask autobump CI and this
guard should help to avoid it.
- Remove check for `cask.depends_on.macos` as it seems to be always
present and set to at least >=10.11
- When we've specified multiple architectures, allow casks to be invalid
on some architectures.
The default behaviour is too strict for unofficial taps. We can still
warn elsewhere but, given the potential for false positives, let's
loosen things a bit.
- change the messaging depending on how confident we are that we're
actually looking at duplicates i.e. we're not confident without a
version number supplied
- similarly, just warn instead of failing with an error (and no
override) if we're not confident that we're looking at duplicates
because a version wasn't supplied
- change `bump-cask-pr` and `bump-formula-pr` to always check for all
pull requests with the new version number (to allow failing on this)
rather than only checking closed pull requests with a version number
- change `bump` to check for definite/maybe duplicate PRs and only
exit if they are definitely duplicates
- cleanup some variable usage to DRY things up a bit
When loading from `tmp_contents` in `bump-cask-pr` we're always loading
from the contents and not from a e.g. filename etc. As a result, skip
the detection of the correct loader (as the regex can be a bit flaky)
and instead use `FromContentLoader` directly.
Don't let users open more than 15 PRs at a time. We have other tooling
to nudge them to not do this but let's put it in the worst offenders:
the `bump*` commands.
Instead output a message that corresponding formula/cask is on the
autobump list. This avoids deferring the information to the error
message within `bump-{formula,cask}-pr`.
Signed-off-by: Michael Cho <michael@michaelcho.dev>
If there are duplicate PRs: we shouldn't suggest and allow a trivial
override. Instead, they should be created manually.
An undocumented override exists for BrewTestBot to do autobumps.
Previously it was possible for both the version and url to be changed.
This would cause the old url to be used to download the cask and check
the checksum since the version and checksum were replaced in the cask
first and then the url would be replaced. This meant that the resulting
checksum was wrong if a url was provided and might be completely
invalid if it was interpolated.
