workflows: cleanup & refactor checkouts

[wolfgangwalther]

The core idea here is to make it harder to accidentally do bad things when checking out nixpkgs in CI. The most obvious thing is to avoid running code from the untrusted PR branch, of course. Just using the terms "merge commit" and "target commit" is not really telling that story, though. So, I renamed the checkout locations to untrusted/ and trusted/ instead. This means you'll have to explicitly write either "trusted" or "untrusted" when referring to any of them, which makes it mostly obvious when executing untrusted code. To encourage this pattern, I'm also moving the the checkouts into actions/get-merge-commit. You'll have to explicitly do something very different to break it now.

Found some inconsistencies, too:

• A bug for PRs with merge conflicts and multiple commits. In this case, the parent of the merged commit is not equal to the target commit, because those are head and base commits of the PRs branch respectively.
• Slight refactor of actions/get-merge-commit to use core.setOutput.
• The nixpkgs-vet workflow... actually executes untrusted code, because it creates a download URL from the pinned version which is taken from the head branch... It doesn't have access to any secrets, so I don't think this is critical. By moving to the pinned nixpkgs instance, provided by the trusted target commitwhich is run in the nix sandbox, this is avoided. Also a regular nix-build ci will now include nixpkgs-vet, too, albeit only running the basic checks, not the "ratchet" checks.
• I would have liked to slightly optimize our checkouts with git worktree, but hit a Nix bug. Slightly annoying to debug, because the lix I am using locally works just fine with worktrees, so that was confusing.

Things done

• Tested in my fork.
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[nixpkgs-ci]

Successfully created backport PR for release-25.05:

• [Backport release-25.05] workflows: cleanup & refactor checkouts #410822

[Mic92]

@wolfgangwalther why do you actually need a .git? Could you not get rid of this before running nix instead of whatever breaks with the current shallow clone worktree? Hopefully the fix in nix is soon there, but just in case.

[wolfgangwalther]

When using worktrees, two things break:

• nix flake check in eval aliases - not sure whether that would work without .git
• nixpkgs-vet, which has this:

  filtered =
    with lib.fileset;
    path:
    toSource {
      fileset = (gitTracked path);
      root = path;
    };

So this does depend on the git repo via gitTracked -> builtins.fetchGit.

It only makes a small difference of a few seconds, so I wouldn't want to introduce more workarounds for it. Once this is fixed in Nix, we can take advantage, though. But it's not blocking anything else either.

[Mic92]

gitTracked

This actually sets shallow = true; but I encountered another bug in nix, where the revCount is computed anyway. This is also fixed in: NixOS/nix#13260

nix flake check can be worked around today by nix flake check git+file:///path?shallow=1. NixOS/nix#13260 make this the new default.

[wolfgangwalther]

gitTracked

This actually sets shallow = true; but I encountered another bug in nix, where the revCount is computed anyway. This is also fixed in: NixOS/nix#13260

Ah, OK. I was about to test that again, because I thought I actually tried adding shallow=1, too. But that should explain my observation.