747d9e2d34
We previously used auto-merge first and then enqueued explicitly on the assumption that auto-merge would fail if the PR was actually in mergeable state already. This turned out to be false. Instead, we currently face the problem of auto-merge sometimes getting stuck. This seems to happen when, at the time of enabling auto-merge, the required status checks already passed and the PR would be ready to go - but sometimes GitHub doesn't do it. This *can* be unblocked by approving the PR again, which seems to run the internal "let's check whether we can merge this" procedures on the GitHub side again. However, we can probably also solve this by just explicitly trying to enqueue the PR first - and only if that fails, fall back to auto-merge. I previously argued against that, based on a potential race condition, in which a PR could become ready to merge between these two requests - at which point the auto-merge operation would fail, if the original assumption was true. But since we don't observe this, we might as well switch.
GitHub specific CI scripts
This folder contains actions/github-script-based JavaScript code.
It provides a nix-shell environment to run and test these actions locally.
To run any of the scripts locally:
- Enter
nix-shellin./ci/github-script. - Ensure
ghis authenticated.
Check commits
Run ./run commits OWNER REPO PR, where OWNER is your username or "NixOS", REPO is the name of your fork or "nixpkgs" and PR is the number of the pull request to check.
Labeler
Run ./run labels OWNER REPO, where OWNER is your username or "NixOS" and REPO the name of your fork or "nixpkgs".