The current version 1.0.7 (in release-25.05) is related to these CVEs.
refs:
* 1.0.7 -> 1.1.1: 97c0a198aa
* 1.2.1 -> 1.2.2: d0beb16463
Not-cherry-picked-because: Updating to 1.2.2 is not suitable for stable channels. This is because version 1.1.1 is not compatible, especially on the package manager side.
This was introduced as part of the hotfix PR to avoid hitting API rate
limits - but the condition was wrong. It was supposed to trigger in all
PR contexts, not only for the Test workflow.
(cherry picked from commit a146035a2b)
Unfortunately it still happens frequently that, after enabling
auto-merge, GitHub is stuck even though all checks have passed, and
doesn't merge the PR. Any contributor can trigger GitHub again with an
approval of the PR - this will then immediately queue the PR for merge.
Adding a hint to the posted comment, should help users through this
without my intervention.
(cherry picked from commit d086c6c6b3)
This lead to reaching secondary API limits in a treewide recently, so we
better limit it to where we actually need it.
(cherry picked from commit cd7f83638e)
We still use a few too many API requests by checking team members for
collaborator status - we can improve on that in the future.
(cherry picked from commit 17199e5ff6)
When hitting a treewide, we would previously find the username for each
user and then check all of them for collaborator status - only to then
realize that this results in more than 15 reviewers and exit.
We can put a simple stop-gap in, even before de-duplicating the combined
lists of maintainers and owners as safe guard. We could still hit huge
numbers of code owners, but in practice we don't nearly as many as
maintainers, so this will be sufficient for now.
(cherry picked from commit 9efe926863)
We use the files endpoint to get a list of all *names* of files touched
in the PR - but this endpoint will also actually download the files /
their diff, too. That's pointless and actually takes quite some time for
huge treewides.
We're just putting in a stop-gap for now, so that we're not burning more
than 1 API requests on this and don't spend so much time on it either. A
limit of 99 files will be more than enough for quite some time - we will
only need to raise this when we're able to represent package sets in
by-name properly and have "package set maintainers", who are not
committers.
(cherry picked from commit 51acc56dcb)
The recent change to use the result of requesting reviewers for setting
the `needs: reviewer` label caused a regression: It would not set the
label for PRs where no reviewers were requested, because *too many were
eligible*. Still - these PRs don't have reviewers, so they need
attention otherwise - via the label.
(cherry picked from commit 4658d0d5a3)
The nixpkgs-ci app now has all the privileges needed to see the member
lists anyway, so no need for two apps / tokens anymore.
(cherry picked from commit 1742aef1e9)
This was introduced shortly before merge of the reviewers.js file, but
not actually tested - I thought it was not easy to find a PR triggering
this warning. However, the scheduled run told me otherwise: The
staging-next PR is the perfect candidate.
(cherry picked from commit d76ffa4136)
We only recently introduced the owners.txt file to the comparison
artifact, so once the bot runs on a schedule it will it older artifacts
very quickly - and then can't find the owners file.
We can fallback to an empty owners list in this case, because an older
artifact also means an older workflow run previously, so this will have
pinged owners already.
(cherry picked from commit c4548e58fb)
This should fix the bug where the "needs: reviewer" label was set too
early, just to be removed immediately, because reviewers were then
requested.
(cherry picked from commit e68b0aef13)
This migrates the bash code to request reviewers to github-script. This
will allow multiple nice improvements later on, but at this stage it's
mostly a reduction in code and complexity.
(cherry picked from commit a23d0ab24c)
We technically counted bot approvals and approvals by deleted users for
the approval labels as well. The former don't exist, yet, but if they
were, I don't think we'd count them. The latter should arguably *not* be
counted, because we can't tell anymore *who* approved, so we can't put
any weight on it as reviewers.
This simplifies the logic, too.
(cherry picked from commit df6a9a739d)
