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.
Michael Daniels