nixpkgs/ci
Wolfgang Walther 0dff5ad6c5
workflows/check: use regular checkout
The filtered checkout we used before was a nice idea, but only worked
for small numbers of commits in a PR. It would fetch the whole history
initially, but only fetch objects on demand. This turns out to be much
too slow in a PR with 18 commits, regularly hitting the 10 minute
timeout, even when running it locally.

The new approach uses regular checkouts again. In contrast to the old
style, before we switched to the filtered checkout, this only fetches
exactly the commits we need - and all of them at once. This is
significantly faster than both other approaches, and scales much better.
A bigger number of commits doesn't have much of an effect, if any at
all.
2025-08-13 14:02:39 +02:00
..
codeowners-validator ci/codeowners-validator: fix typo in comment 2025-06-02 16:06:16 +02:00
eval ci/eval/compare: reorder step summary 2025-08-12 10:13:56 +02:00
github-script workflows/check: use regular checkout 2025-08-13 14:02:39 +02:00
request-reviews
default.nix nix_2_3: drop 2025-08-12 11:28:40 +02:00
nixpkgs-vet.nix ci/nixpkgs-vet: add badFiles and conflictingPaths checks 2025-06-10 15:10:52 +02:00
nixpkgs-vet.sh ci/nixpkgs-vet.sh: fix passing arguments 2025-06-12 20:30:36 +02:00
OWNERS ci/OWNERS: reduce firefox package ownership 2025-07-29 19:18:15 +02:00
parse.nix ci/parse: init 2025-05-11 12:14:57 +02:00
pinned.json ci/pinned: update 2025-08-12 10:14:01 +02:00
README.md ci/README.md: one sentence per line 2025-06-29 21:14:33 +02:00
supportedBranches.js workflows/pr: refactor base/head branch decision making 2025-06-22 14:21:03 +02:00
supportedSystems.json workflows/eval: load supportedSystems from JSON file 2025-05-11 22:22:45 +02:00
supportedVersions.nix workflows/eval: test all available versions 2025-08-12 10:14:01 +02:00
update-pinned.sh ci/pinned: manage nixpkgs and treefmt-nix with npins 2025-06-02 09:13:11 +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.json contains a pinned Nixpkgs version tested by Hydra.

Run update-pinned.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.

Branch classification

For the purposes of CI, branches in the NixOS/nixpkgs repository are classified as follows:

  • Channel branches
    • nixos- or nixpkgs- prefix
    • Are only updated from master or release- branches, when hydra passes.
    • Otherwise not worked on, Pull Requests are not allowed.
    • Long-lived, no deletion, no force push.
  • Primary development branches
    • release- prefix and master
    • Pull Requests required.
    • Long-lived, no deletion, no force push.
  • Secondary development branches
    • staging- prefix, haskell-updates and python-updates
    • Pull Requests normally required, except when merging development branches into each other.
    • Long-lived, no deletion, no force push.
  • Work-In-Progress branches
    • backport-, revert- and wip- prefixes.
    • Deprecated: All other branches, not matched by channel/development.
    • Pull Requests are optional.
    • Short-lived, force push allowed, deleted after merge.

Some branches also have a version component, which is either unstable or YY.MM.

ci/supportedBranches.js is a script imported by CI to classify the base and head branches of a Pull Request. This classification will then be used to skip certain jobs. This script can also be run locally to print basic test cases.