Skip to content

ci: add package version diff comment on PRs - #2450

Open
brainrake wants to merge 3 commits into
developfrom
ci/nix-version-diff
Open

brainrake wants to merge 3 commits into
developfrom
ci/nix-version-diff

Conversation

@brainrake

@brainrake brainrake commented Sep 14, 2026

Copy link
Copy Markdown
Collaborator

Reviving #2299 . This can be used instead of Nix Dependency Analysis workflow as a much faster alternative that won't run out of disk space so easily.

  • Evaluates every derivation's drvPath under legacyPackages.<system> on the PR's head and base commits (pure evaluation — no network, no build).
  • If nothing differs, reports that directly with zero further work.
  • If something differs, only the changed/added/removed attrs are built (substituted from the shared cache) and diffed with nvd — the rest of the closure is never touched.
    Results are posted as a single collapsed comment per PR, updated in place on subsequent pushes.

Example — no differences: see #2299 ' s first comment.
Example — with a real diff (added package): #2306

Adds a version-diff job that compares every legacyPackages.<system>
derivation between a PR's head and base commit and posts the result as
a collapsed comment (one <details> per system, folded into its
summary line), using nvd for the actual version/added/removed diff.

Enumerates legacyPackages directly (via a small linkFarm collector
expression) rather than relying on nix-eval's packages_matrix, since
that matrix only lists not-yet-cached packages and goes stale/empty
once a PR's packages are built and cached -- the wrong signal for "did
anything change vs base".

Uses a GitHub App token via actions/create-github-app-token so the
comment step isn't blocked by the org's "Actions can't create/approve
PRs" policy, and grants pull-requests: write only to the comment job.
Building the entire legacyPackages closure on both sides just to nvd-diff
two roots meant realizing ~700+ store paths per side per arch even when
only one package changed -- most of that time was substituter narinfo
lookups and downloads, not building anything.

Evaluate each attr's drvPath (pure evaluation, no network) on both sides
first. Equal maps mean no changes, decided without touching the store at
all. Otherwise only the attrs whose drvPath actually differs get built
and nvd-diffed; added/removed attrs are reported directly.
@brainrake
brainrake requested review from a team as code owners September 14, 2026 15:18
@github-actions

Copy link
Copy Markdown

Package version diff: none

Compares built package versions in legacyPackages between this PR and its base commit, per system.

No Package Differences

All packages are hash-identical on all systems (aarch64-darwin,aarch64-linux x86_64-linux).

Comment on lines +317 to +328
- name: Install nix (ephemeral)
if: matrix.installer == 'ephemeral'
uses: ./head/.github/actions/nix-install-ephemeral
with:
push-to-cache: 'true'
env:
DEV_AWS_ROLE: ${{ secrets.DEV_AWS_ROLE }}
NIX_SIGN_SECRET_KEY: ${{ secrets.NIX_SIGN_SECRET_KEY }}

- name: Install nix (self-hosted)
if: matrix.installer == 'self-hosted'
uses: ./head/.github/actions/nix-install-self-hosted

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure nix-install-ephemeral can be used for the arm darwin runners too.

Comment on lines +330 to +336
# nix-eval's packages_matrix only lists *uncached* packages, so it
# cannot be used to decide what to diff. Instead, evaluate every
# derivation's drvPath under legacyPackages.<system> (recursing into
# attrsets like nix-eval-jobs --force-recurse does) on both sides.
# drvPath captures any input change (source, patches, deps, build
# steps), not just a bumped version string, and evaluating it is pure
# -- no substituter queries, no downloads, no builds.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth uploading the nix-eval-job's output as a build artifact that you can then fetch here? This way don't waste time eval'ing all the things twice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants