- Add an `--organisation` flag to search a specific organisation.
- Wait for the GitHub API rate limit to reset before automatically
retrying.
- Use (much) fewer API calls by using organisation-wide API PR searches
rather than per-repository. This makes the rate limit easier to avoid
and also makes things much faster (with the trade-off of showing a max
PR count per-user rather than per-repository).
- Improve output to clarify when the max PR/commit count is reached.
- Move more logic and add more Sorbet signatures to the `GitHub` and
`Utils::Git` modules.
- Rename a few GitHub API methods.
- Remove a lot of (now unused) `GitHub` module methods.
- Add, use a `Tap#full_repository` method.
- Add `formula-analytics` as a deprecated tap.
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).
I ran `brew livecheck` today to check the packages in my watchlist
and realized that it wasn't checking one package because I had added
a trailing comment after the name (and `package # Comment` isn't a
valid package name). I thought we had added support for trailing
comments when we originally added comment support years back but I
must have been mistaken.
This adds support for trailing comments in livecheck watchlist files
as part of refactoring the watchlist line parsing logic to only use
one pass (instead of multiple `#map` and `#reject` calls). This
maintains the existing behavior, where blank lines and lines starting
with `#` are skipped, but does so in a more flexible manner. For
example, the existing logic wouldn't skip a comment line that has one
or more spaces before the `#` character but this new logic will
correctly skip it.
`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.
We sometimes see errors like "attempted to use a `Downloadable`
without a URL!" in the homebrew/cask autobump workflow log because
`bump-cask-pr` can simulate Linux even if a cask doesn't support it,
leading to this error. This is something that should be resolved in
the future once I finally wrap up my related work to detect OS/arch
requirements but this adds a simple guard to address this in the
interim time.
`HOMEBREW_FORCE_BREW_WRAPPER` can be used as a security/compliance
feature, but allowing it to be disabled by setting
`HOMEBREW_NO_FORCE_BREW_WRAPPER` leaves a pretty large hole in it that
allows it to be sidestepped.
Let's fix that by actually checking the path of the process that called
`brew`, and the verify that that path matches the configured value of
`HOMEBREW_NO_FORCE_BREW_WRAPPER`.
