0
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2025-07-14 14:10:33 +03:00
nixpkgs/ci
Wolfgang Walther 856792f93e
workflows/check-cherry-picks: truncate long diffs after 10k characters
GitHub comments have a length limit, so we can't just dump everything.
The 10k limit is arbitrary, but the assumption is that reviewing the
range-diff is not the sensible thing to do once it becomes a certain
size - reviewing the regular diff and treating the commit as "new" is
easier to do in that case. Thus, truncating should work out fine,
especially when the full range-diff is still available in the runner
log.

This could still end up in with an error, if a PR has multiple commits,
which all hit the limit. Let's get there first, before we try to fix
that hypothetical case, too.
2025-06-01 09:35:51 +02:00
..
codeowners-validator ci: Add codeowners validator 2024-10-08 22:14:59 +02:00
eval ci/eval: don't evaluate packages marked as broken (#409867) 2025-05-28 13:36:19 +00:00
nixpkgs-vet nixpkgs-vet: update CI, docs, and release to 0.1.4 2024-09-03 13:53:25 -07:00
request-reviews ci/request-reviews: Don't fail when there's too many reviewers 2025-01-20 19:45:28 +01:00
check-cherry-picks.md workflows/check-cherry-picks: post review comments 2025-06-01 09:35:47 +02:00
check-cherry-picks.sh workflows/check-cherry-picks: truncate long diffs after 10k characters 2025-06-01 09:35:51 +02:00
default.nix workflows/manual-nixpkgs: build nixpkgs manual on staging and stable branches 2025-05-29 17:06:40 +02:00
nixpkgs-vet.nix workflows/nixpkgs-vet: use nixpkgs-vet from pinned nixpkgs 2025-05-25 15:01:42 +02:00
nixpkgs-vet.sh workflows/nixpkgs-vet: use nixpkgs-vet from pinned nixpkgs 2025-05-25 15:01:42 +02:00
OWNERS OWNERS: add owners for authelia files 2025-05-28 21:49:14 +02:00
parse.nix ci/parse: init 2025-05-11 12:14:57 +02:00
pinned-nixpkgs.json ci: Update pinned Nixpkgs 2025-05-29 16:27:56 +02:00
README.md workflows/get-merge-commit: inline get-merge-commit.sh script as github-script 2025-05-23 23:05:26 +02:00
supportedSystems.json workflows/eval: load supportedSystems from JSON file 2025-05-11 22:22:45 +02:00
update-pinned-nixpkgs.sh ci/update-pinned-nixpkgs.sh: Allow setting the rev 2024-07-18 15:51:02 +02:00

CI support files

This directory contains files to support CI, such as GitHub Actions and Ofborg. This is in contrast with maintainers/scripts which is for human use instead.

Pinned Nixpkgs

CI may need certain packages from Nixpkgs. In order to ensure that the needed packages are generally available without building, pinned-nixpkgs.json contains a pinned Nixpkgs version tested by Hydra.

Run update-pinned-nixpkgs.sh to update it.

ci/nixpkgs-vet.sh BASE_BRANCH [REPOSITORY]

Runs the nixpkgs-vet tool on the HEAD commit, closely matching what CI does. This can't do exactly the same as CI, because CI needs to rely on GitHub's server-side Git history to compute the mergeability of PRs before the check can be started. In turn, when contributors are running this tool locally, we don't want to have to push commits to test them, and we can also rely on the local Git history to do the mergeability check.

Arguments:

  • BASE_BRANCH: The base branch to use, e.g. master or release-24.05
  • REPOSITORY: The repository from which to fetch the base branch. Defaults to https://github.com/NixOS/nixpkgs.git.

ci/nixpkgs-vet

This directory contains scripts and files used and related to nixpkgs-vet, which the CI uses to implement pkgs/by-name checks, along with many other Nixpkgs architecture rules. See also the CI GitHub Action.

ci/nixpkgs-vet/update-pinned-tool.sh

Updates the pinned nixpkgs-vet tool in ci/nixpkgs-vet/pinned-version.txt to the latest release.

Each release contains a pre-built x86_64-linux version of the tool which is used by CI.

This script currently needs to be called manually when the CI tooling needs to be updated.

Why not just build the tooling right from the PRs Nixpkgs version?

  • Because it allows CI to check all PRs, even if they would break the CI tooling.
  • Because it makes the CI check very fast, since no Nix builds need to be done, even for mass rebuilds.
  • Because it improves security, since we don't have to build potentially untrusted code from PRs. The tool only needs a very minimal Nix evaluation at runtime, which can work with readonly-mode and restrict-eval.