The performance comparison summary previously stated it compared against
"its pull request base branch (e.g., 'master')" regardless of the actual
base branch.
Plumb the base branch classification computed in prepare.js through the
eval workflow to the `compare` derivation so the summary names the real
base branch (e.g. "staging-25.11"). The local `eval.full` helper defaults
to "master", matching its touched-files convention.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
When testVersions is enabled, the version matrix check now identifies
the specific commit that modified ci/pinned.json, rather than evaluating
the full PR. This allows formatting changes and other modifications to
coexist in the same PR without affecting the hash consistency check.
The workflow now:
- Adds headSha input to compare PR commits against target
- Finds the single commit that touched ci/pinned.json
- Errors if multiple commits modify it (to ensure clear attribution)
- Passes the bump commit to the checkout action for isolated evaluation
- Reports which commit was evaluated in the summary
The actual cherry-pick and pinned checkout handling is delegated to
the checkout action via the new `untrusted-pin-bump` input.
Co-Authored-By: Matt Sturgeon <matt@sturgeon.me.uk>
This is in public preview now. These runners run in a docker container
with only a single vCPU instead of 4 like the other jobs. For most of
our jobs, this should be plenty, except for eval and linting.
Evaluating untrusted code in the presence of secrets is unsafe in
general, thus we only provide the cachix auth token when these jobs run
in the merge queue. This is enough for all practical purposes, PRs will
be able to pull stuff from cachix that was built in the Merge Queue
previously.
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.
We still get plenty of errors in the prepare step for the diff requests
to take way too long - let's increase the number of retries massively
now. These are repeated with exponential backoff, so hopefully they will
succeed with some cooldown, when GitHub had time to compute the right
diff in the background.
This workflow / script is already doing more than must labeling: it's
already auto-closing package request issues.
Since we're going to migrate the nixpkgs-merge-bot into this workflow,
we'll rename things to a more generic name.
To be able to disable the pr.yml workflow on GitHub, we need to rename
it to a different name. Let's use the long name for consistency with
merge-group.yml. This only affects the GitHub-internal name, not the
visible name in the PR checklist, which is still "PR". This visible name
is also used by nixpkgs-review, so that won't break.
