f7d6d11e8e
This removes the "owners" check from codeowners-validator. With it, all tokens and permissions can be removed, because these were only needed to make these requests. This solves the problem of codeowners-validator not supporting our new nested team structure for nixpkgs-maintainers. To make the onboarding of new teams easier, we moved all teams "under" the nixpkgs-maintainers team. This makes them inherit the right privileges (triage) for Nixpkgs. However, this inheritance is not recognized by codeowners-validator, thus it assumes that these teams don't have access to Nixpkgs. This then fails the owners check immediately. Removing the owners check also has a few other advantages: - This check depends on external state: If a user is renamed or a team removed, the check will fail. This makes it a bad check for required status checks or merge queues - the check might fail randomly, independent of the current PR. - Running this check in a fork will never work, because the respective users and teams don't have access to the fork's repo. Both of this required us to set `continue-on-error: true` most of the time. |
||
|---|---|---|
| .. | ||
| codeowners-validator | ||
| eval | ||
| github-script | ||
| request-reviews | ||
| default.nix | ||
| nixpkgs-vet.nix | ||
| nixpkgs-vet.sh | ||
| OWNERS | ||
| parse.nix | ||
| pinned.json | ||
| README.md | ||
| supportedBranches.js | ||
| supportedSystems.json | ||
| supportedVersions.nix | ||
| update-pinned.sh | ||
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.05REPOSITORY: 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-ornixpkgs-prefix- Are only updated from
masterorrelease-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 andmaster- Pull Requests required.
- Long-lived, no deletion, no force push.
- Secondary development branches
staging-prefix andhaskell-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-andwip-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.