Previously, headRef points to the master branch of Nixpkgs, which
basically means no code owner review will be requested.
The problem can be verified using the following command.
$ DRY_MODE=1 ./ci/request-reviews/request-reviews.sh NixOS/nixpkgs 347973 ci/OWNERS
[...]
This PR touches 0 files
Requesting reviews from: {
"reviewers": []
}
[...]
Additionally, the comment about conflicts is removed thanks to the
unambiguous way of specifying ref.
Turns out if :<something> is passed, a local branch is updated, which
can conflict if the PR branch starts with "pr". I tried to avoid that
with the original code but apparently that didn't work!
https://github.com/NixOS/nixpkgs/actions/runs/11284183639/job/31384967152?pr=347822
Fetching the PR commit history
From https://github.com/linj-fork/nixpkgs
* [new branch] pr/kanata-add-version-check -> fork/pr
error: cannot lock ref 'refs/remotes/fork/pr/kanata-add-version-check': 'refs/remotes/fork/pr' exists; cannot create 'refs/remotes/fork/pr/kanata-add-version-check'
! [new branch] pr/kanata-add-version-check -> fork/pr/kanata-add-version-check (unable to update local ref)
error: some local refs could not be updated; try running
This makes this codeowner mechanism behave differently than the native
one, but there's no other way to avoid rerequesting reviews from teams
when a member already reviewed the PR.
The automation should never rerequest reviews from users that already
reviewed the changes, which is what was happening before this change:
https://github.com/NixOS/nixpkgs/pull/347354#event-14570645380
Also reorder the arguments to make more sense
Also post a comment in case base branch is wrong
This guides newcomers in how to smoothly handle the potentially scary
situation of having thousands of commits listed in a PR.
While CI shows the same, people might not even look at CI if the PR
looks botched.
