See comment, but TLDR this is for backwards-compatibility.
(See 479628, where it failed to dismiss after fixing.)
We don't bother with `prepare.js` because it always errors
(and so should never be dismissed).
I have simply added the needed comments to each of `check-target-branch.js`'s
pre-existing reviews, because there are so few.
You can technically have multiple reviews requesting changes, but
there's no good way to dismiss all of the reviews requesting changes from
the same user using the UI.
This makes minimization impossible (because all but one of the reviews is not
dismissed, even though the PR is no longer blocked due to the review
in GitHub's system).
As a workaround, we will only comment.
CI will still fail when appropriate.
Checks all PR commit messages for version update pattern
like 'packagename: X.Y.Z -> A.B.C'.
Matches: 1.2.3, 0-unstable-2024-01-15, 1.3rc1, alpha, unstable
Apparently any effects from this change haven’t shown up noticeably
in GitHub’s metrics, to the point where they’re not sure if it
was taking effect on the backend. Our contact is going to look at
getting something into the API response to help debug whether it’s
actually working or not, but agreed that we should just revert for
now. Since they have apparently reduced replica sync issues further
through other changes on their end, there shouldn’t be any urgent
need to make any changes here anyway.
This reverts commit 18b30c8ce1.
When a maintainer deletes their GitHub account, the bot would crash with a 404 error when trying to fetch their user info via `/user/{id}`.
This caused the scheduled bot workflow to fail repeatedly until manual intervention (e.g., closing/reopening the affected PR to clear the requested reviewer).
Fix by returning null from getUser() for 404 responses and filtering out null users when building the reviewers list.
Dismissals are done automatically by commits.js, even for reviews from
check-target-branches.js. This is not desirable.
The solution is
(1) do not decline to post a review because it was already dismissed
(because it may have not been dismissed by a human, and circumstances may
have changed), and
(2) reword the auto-dismissal message to not imply that whatever
problems were present are fixed.
This restricts github automatically merging master with commit message
"Merge branch 'NixOS:master' into ...". Although we don't explicitly
prohibit not space after colons, we don't use it in any of the examples.
It's also enforced in https://www.conventionalcommits.org/en/v1.0.0/
Follow-up to 7cf5972410
While the JS script already returned early, we can save a few resources
by skipping the job entirely when there's no `pull_request` context.
This is an experiment and can be reverted a few days from now; if
the results are positive on GitHub’s end, then we may want to make
the merge conflict checks run less frequently than the rest of the
labelling tasks.
I fixed this for the maintainer maps, but the artifact that was causing the
particular issue that prompted me to try to fix it was actually the
pagination cursor. So fix that too.
Related: #464046.
The prepare script is currently failing for staging-25.11 PR's, because
it assumes that a release-25.11 exists respectively. This is not the
case in the transition phase before branch-off.
We can fix this by always including the current target branch in the
branches to check for, even if it's not a WIP branch. This means we
might check some branches twice, but that's better than erroring out
entirely when the branch is in fact correct.
This reverts commit 402b41c125.
GitHub' API repeatedly returns wrong data which causes closed PRs when
the changes had not been merged, yet.
We have closed a bit more than 100 PRs overall, most of them initially -
the feature is not really that important overall.
It makes not much sense to run all the checks for PRs when we can
already tell they are stale beforehand. In particular this should avoid
creating ~3.3k temporary merge commits every day, for PRs that surely
won't have had any change.
The number of merge commits *could* play a role in the growing size of
the fork network. We'll have GitHub look into the metrics before and
after this change to see whether that is any improvement.
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.
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.
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.
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.
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.
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.
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.
