This script assumed to get lowercased input before, but with the
addition of pinging maintainers that's not necessarily true anymore.
Since the checks for prAuthor and already-reviewed-by already lowercase,
make sure to lowercase the handles in the users array, too.
Fixes this problem for maintainer-based reviews when the maintainer
didn't yet accept or missed the automated invite:
gh: Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the NixOS/nixpkgs repository. (HTTP 422)
With the release of 2.3.0-rc, we know that 2.3.0 will be coming sometime
soon. Per the [ZFS release policy][1], only the current and previous
releases are expected to be supported, so 2.1.x will become unsupported.
Unfortunately upstream does not have any specific timelines, so we do
not know when it will become unsupported, but when it does we will
likely backport the removal. As such, begin warning of imminent removal.
[1]: 6187b19434/RELEASES.md
The handles can change over time and there's nothing guaranteeing the
ones in the maintainer list are up-to-date. In comparison GitHub IDs
never change.
Currently we need to rely on ofborg requesting reviews from package
maintainers, which takes a while with ofborg's eval queue. Since
recently we're doing faster evaluations with GitHub Actions, which contain all
necessary information to determine reviewers of changed packages the
same way ofborg does. This PR takes advantage of that.
It's currently annoying to see the actual failure in the attrs step,
because `time -v` displays like 20 lines, which get repeated, therefore
requiring you to scroll up most of the time:
3429721834 (step):5:794
This commit fixes that by only displaying the most important stats, the
same ones as the chunked system-specific evals.
The workaround to have ofborg ping chromium and ungoogled-chromium
maintainers when a change was only made to the upstream-info relied on
string context.
That string context was provided by the upstream-info being a nix file,
not a json file, and then holding on to that string context using
awkward attribute merges.
It was intended as a quick fix until the handling of this would improve
in ofborg itself and worked great.
That was until very recently when we switched from the chromium release
tarball to git source fetching in 8dd2f1add9.
Part of that change included going back from upstream-info.nix to
upstream-info.json and with that losing the string context and the base
on which this workaround used to work.
But this is fine. A lot has happened in the meantime.
CODEOWNERS was reimplemented and no longer requires every user listed in
it to have write permissions to the repository (commit bit).
Meaning we can accept that ofborg pings no longer work and instead rely
on CODEOWNERS exclusively.
It should, however, be noted that CODEOWNERS provide less granularity
than ofborg, meaning we can no longer differentiate between
ungoogled-chromium and chromium or even chromedriver.
Previously, implementing the workaround that is now essentially
reverted: 68c59791fb
It is within our scope.
The general team consensus seems to be that it is in a similar position
to nix-ld: in-tree users should migrate away from it, but out-of-tree
users can use it as a workaround, in place of a wrapper.
