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
Previously the eval comparison was skipped entirely when packages were
added or removed between revisions, leaving only a "stats were skipped"
message. cmp-stats already joins on the stats chunks present in both
revisions, so a comparison can still be produced. Always run it and add
a GitHub note caveating that the figures are approximate when the
package sets differ.
Assisted-by: claude-code with claude-opus-4-7[1m]-xhigh
I don't think the worry about confusion applies anymore because nowadays CI
will tell you if you target staging-nixos when you should be targeting staging.
On the other hand, I was confused why kernel updates didn't show up as
NixOS test rebuilds...
This is a functional change, but there's no known consumer of this
interface, and if we want to trigger review request for PRs it's
convenient for these paths to be absolute
ci: Trigger review requests for module maintainers
This moves the parsing of ci/OWNERS into the Nix sandbox. We also get
rid of checking out the nixpkgs repo another time in the reviewers
workflow - we already have everything we need in the eval/compare job.
The creation of owners.txt in this way is only temporary, it should
eventually be moved further, similar to how maintainers.json is
currently migrating to a maintainer map for the whole repo stored on the
target branch as artifact.
Instead of setting the maintainer-related labels based entirely on Eval
results, this uses the new maintainer map from the target branch. This
allows labeling PRs correctly, that had been created *before* a
contributor became a maintainer of the respective package.
In a recent change, the path matching was simplified in maintainers.nix.
This revealed a pre-existing logic bug: Packages without `meta.position`
would get an empty string as their file name. The change would then
cause this empty string to always be matched, which lead to maintainer
pings for these packages in seemingly random PRs, when some of their
dependencies were changed.
We should never try to ping maintainers through package aliases, this
can only lead to errors. One example case is, where an attribute is a
throw alias, but then re-introduced in a PR. This would trigger the
throw. By disabling aliases, we can fallback gracefully.
This allows requesting reviewers for pure refactor PRs, which don't
cause a rebuild of the package. This is only possible for by-name,
because only here the package names can be inferred from the filenames.
This adds support to ping maintainers when arbitrary files in by-name
are changed, as long as they still cause a rebuild. For example, this is
the case when changing .json files with version metadata. These were
previously not detected as belonging to the package, and didn't cause
maintainer pings.
The only reason for the additional `lib.hasSuffix` check was, that the
`lib.removePrefix` was broken - it was never adjusted when porting this
from ofborg, so the relative path was wrong and no prefix ever removed,
since no packages are in `ci/`.
This additionally strips the leading `/`, so that `relevantFilenames`
will then have paths starting with `pkgs/...`, similar to how git
reports those paths in the `changedpathsjson` file. This allows simple
equality comparison.
This reverts commit f8210561f3 (ci.eval.compare: turn warnings into errors, 2025-09-16).
It turns out that there are normal math warnings and we don't want to block CI on the math coming out wrong.
Aliaksandr