- 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.
- The `API_MAX_PAGES` value is 50, so for pages 1 to 50, the
`paginate_rest` method was making an API call even if there was no
data past, for example, page 8.
- This made `brew contributions --user=issyl0` take 11 minutes, since we
made 50 API calls _per repo_ even if it was unnecessary, burning down
our API allowance.
- Instead, stop looping if we detect that there's no data in `result`.
- This probably needs more testing for other parts of Homebrew that rely
on `paginate_rest` and the different shapes of data it outputs.
- 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.
- This 404 error is from GitHub, and GitHub doesn't give us any more
informations about scopes for the gist endpoint (for some reason). But we can
safely assume, as it happens a lot, that "Error: Not Found" (404) is because
the user hasn't granted their `HOMEBREW_GITHUB_API_TOKEN` the `gist` scope.
Before:
```shell
$ HOMEBREW_GITHUB_API_TOKEN=<token_without_gist_scope> brew gist-logs -p logrotate
Error: Not Found
```
After:
```shell
❯ HOMEBREW_GITHUB_API_TOKEN=<token_without_gist_scope> brew gist-logs logrotate
Error: Your GitHub API token likely doesn't have the `gist` scope.
Create a GitHub personal access token:
https://github.com/settings/tokens/new?scopes=gist&description=Homebrew
echo 'export HOMEBREW_GITHUB_API_TOKEN=your_token_here' >> ~/.zshrc
```
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.
