- Both `from` and `to` are now separate keyword arguments
in a bunch of places, not part of `args`.
- When we switched this around, we didn't realize this
method needed updating to correctly construct the time
range query.
- This led to further inaccurate counts in `brew contributions`
for reviews, since `from` and `to` are not valid search qualifiers
for the GitHub PR search APIs.
- This was broken (I did have a commit SHA for the breakage but I can't find it now) since `from` and `args.from` are different variables (one can be nil, the other has a default value).
- So it was reporting very high counts because, despite the message, the `from` restriction was not being passed to `count_repo_commits`.
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.
