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.
We early return here
92a4311868/Library/Homebrew/utils/github/api.rb (L220)
, but don't then handle that through the stack.
Repro:
```console
❯ HOMEBREW_NO_AUTO_UPDATE=1 HOMEBREW_NO_GITHUB_API=1 brew bump-formula-pr --write-only --version 1.2.3 --no-audit jq
Error: undefined method `[]' for nil:NilClass
Do not report this issue until you've run `brew update` and tried again.
Warning: Removed Sorbet lines from backtrace!
/opt/homebrew/Library/Homebrew/utils/github.rb:565:in `block in fetch_pull_requests'
/opt/homebrew/Library/Homebrew/utils/github/api.rb:334:in `paginate_graphql'
/opt/homebrew/Library/Homebrew/utils/github.rb:564:in `fetch_pull_requests'
/opt/homebrew/Library/Homebrew/utils/github.rb:628:in `check_for_duplicate_pull_requests'
/opt/homebrew/Library/Homebrew/dev-cmd/bump-formula-pr.rb:456:in `check_open_pull_requests'
/opt/homebrew/Library/Homebrew/dev-cmd/bump-formula-pr.rb:135:in `run'
/opt/homebrew/Library/Homebrew/brew.rb:89:in `<main>'
Rerun with `--verbose` to see the original backtrace
```
- Some repositories occasionally change their licenses. For example they
release a version of the software with one license and then decide to change
the license later.
- Now that `?ref=` is a parameter to the GitHub Repositories License API,
we can use that in the license audit to check if the license of the specific
release matches the one declared in the formula.
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.
- more sensible/performant defaults: default to primary repositories
only for the last year rather than all repositories forever
- allow specifying more than one user at a time
- output the breakdown of contributions without needing `--csv`
- add a space before the `--csv` output
- consolidate some code
- avoid counting authored commits twice, to improve performance
- retry failed GitHub API calls (this happens often when querying all
maintainers)
- stop counting after we find 1000 commits for a given user to avoid
excessive API queries/pagination
- This change is useful for the "these issues are also open for this
build failure" exception. Hopefully there'll be less noise on PRs with
people encouraging us to fix things faster if we don't link them to
WIP PRs (or any PRs at all).
- Fixes https://github.com/Homebrew/brew/issues/ 15608.
We currently use the search API to check for duplicate pull requests,
but this is not very reliable. Our `autobump.yml` workflow routinely
opens duplicate pull requests [1] because the search API often returns
incorrect results.
We can make this more reliable by using the Pulls API instead.
Unfortunately, querying the Pulls API is very slow (~10s vs less than a
second for the search API), so let's limit its usage to calls made
inside CI, which should help @BrewTestBot avoid opening duplicate PRs.
(Most recent dupes were authored by @BrewTestBot.)
[1] https://github.com/Homebrew/homebrew-core/pulls?q=is%3Apr+author%3ABrewTestBot+is%3Aunmerged+in%3Acomments+Duplicate
- The usage of this in `brew contributions` wasn't correct for a user
with 5 authored commits to homebrew/cask that had been committed by
other people, the numbers would turn out as 5 authored, 5 committed.
- I decided to do this properly by getting the SHAs for author and
committer and determine the differences between the two arrays.
This also accounts for when authored commits are 0, or committed
commits, or both.
- Add tests, because I don't want to fix this a third time!
- The GitHub list commits API now supports this filtering
(https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-commits--parameters),
because I wrote it. :-)
- Authoring a commit and committing a commit are two separate concepts: author
is the person who wrote the code and, in old parlance, the committer is the
person who applied the patch (remember when we sent patches to mailing lists?).
- In practice for us in Homebrew, this occurs when we make a change in GitHub's
web editor, or, more obviously, when BrewTestBot pushes `homebrew-core`
commits from users (then, `BrewTestBot` is the `committer`).
- Now `brew contributions --from=2023-02-23 --to=2023-02-26` works to limit the
results for reviews. I forgot this in the original implementation, again,
ugh.
- The search APIs don't have that high a rate limit but we shouldn't need to
worry about that too much because, to get counts, the JSON response comes
with a `total_count` number.
- Functionally it doesn't matter that the URL will have an `&` at the
end if `additional_query_params` is `nil`, because it doesn't affect
the URL at all.
- These are arbitrary length limits that had a load of disables in code.
- The limits were only increasing over time rather than decreasing.
- Fixing the problematic code to be shorter would take a long time for
questionable gain since the problem has been around so long.
- Using `git log` was brittle with name changes and email address changes for
contributors over the years unless we made a Git `mailmap` file which brings
with it its own updatedness overhead.
- Let's use the GitHub commits API (importantly _not_ the search API) so that
we can give it a username and it will return contributions associated with
every email address on that user's account:
https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-commits--parameters.
- This is quite significantly slower, but it's worth it for correctness
especially when we get to all maintainers' contributions (in a separate PR).
- The commits API does not (yet?) support trailers or commit "committer"s, just
authors.
- We're not going to make the really long things be any shorter any time soon.
- The instructions in issue 14685 say, pragmatically, "disable all the rubocop
rules we're never going to realistically fix e.g. Metrics/ClassLength". But
that felt like a slippery slope to more _really_ long modules/classes/blocks,
and the limits are here for a reason.
Currently we only check for closed PRs in
`bump-cask-pr`. This adds that check to `bump`
and `bump-formula-pr`. The idea is that this
check can warn users about already updated
packages or those that can't be updated
easily and should be updated manually instead.
