When `Enumerable#all?` is called without an argument, it should check
whether values are truthy but it doesn't appear to work as expected
for the `newer_than_upstream` hash. In this case,
`{ general: false }.all?` returns `true` when it seemingly should
return `false`. This is preventing autobump from opening PRs for new
versions, so I've updated related `all?` calls to use a block with an
explicit comparison to `true` as a workaround to fix autobump in the
immediate term.
I recently modified `bump` to show the upstream version even when the
formula/cask version is newer (instead of an opaque `Unable to get
versions` error) but I noticed an issue while reviewing output from
a recent autobump run in homebrew/cask. This change works as expected
for versions with only one part (e.g., 1.2.3) but some multipart cask
versions (e.g., 1.5,15039) aren't being handled like they should
(where we split on commas and compare the version parts separately).
As a result, a cask version like 1.5,15039 is incorrectly seen as
newer than an upstream version like 1.5.1,15145 because 15039 from
the cask version is being compared to 1 in the upstream version.
This addresses the issue by using `LivecheckVersion` objects in the
related comparison, so versions will be handled as expected. This was
an oversight on my part but it only affects one cask at the moment
(`ia-presenter`), so it wasn't a widespread issue.
Currently `brew bump` will output `unable to get versions` for the
livecheck (or Repology) version if it's lower than the current
package version. This makes it impossible to distinguish between a
failing livecheck and one where the livecheck version is lower. We can
detect when the package version is newer than the upstream version but
`bump` doesn't do anything to handle the situation.
This addresses the issue by updating `bump` to display the lower
upstream version and flag the current version with a trailing "(newer
than upstream)" parenthetical to make the situation apparent (and so
we can easily search for this text in the output).
`brew bump` understands that some formulae/casks are skipped by
livecheck but it doesn't use this information to avoid doing
unnecessary or inappropriate work. This modifies related logic to not
fetch PR information or try to open a version bump PR if livecheck is
skipped. livecheck is our only source of version information these
days, so we can't try to version bump a package if we don't have
upstream version information.
This has been leading to an "Invalid usage: `--version` must not be
empty" error and this _should_ fix the issue under these particular
circumstances. There's still plenty of room for improvement in how
all of this is handled in bump but this is just a quick bug fix.
`ensure_formula_installed!` requires the `Formula` class to be loaded
before being called to work properly.
Let's guarantee that instead by implementing it as an instance method of
the `Formula` class.
See discussion at #20358.
I do not like that `brew bump` command checks every single formula/cask,
even ones updated by BrewTestBot. Instead of showing useful info about
outdated packages, my terminal buffer is fludded with `Formula is
autobumped so will have bump PRs opened by BrewTestBot every ~3 hours`.
This flag excludes autobumped packages before checking them.
Signed-off-by: botantony <antonsm21@gmail.com>
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".
`brew bump` will check for PRs related to a package even if livecheck
fails to identify new versions. This reworks related conditions to
ensure that related PR checks are only run when livecheck returns
version information.
`brew bump` will check for PRs related to a package even if the
package version and livecheck version are the same. We're presumably
only interested in related PRs when the livecheck version differs, so
we can reduce GitHub API requests by skipping the check(s) when the
versions are equal. We use `bump` in `autobump` workflows, so this
should help with recent rate limiting issues (e.g., 3203 out of 3426
autobumped formulae were up to date in a recent run).
This also reworks the output for duplicate PRs, making it clear when
`bump` skipped checking PRs (as printing "none" would suggest that
PRs were checked) and only printing the "Maybe duplicate" information
when checked. This makes it a little easier to understand what `bump`
has done internally from the output.
- 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
A recent commit reworked `require`s to improve performance but this
led to an `uninitialized constant Homebrew::DevCmd::Bump::Repology`
error in `brew bump`. This adds a `utils/repology` `require` to
`dev-cmd/bump.rb` to resolve the error.
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.
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.
