9bea5d3844
This workflow runs the PR and Push workflow files on a `pull_request`
trigger. The intent is to test changes to the workflow files
immediately. Previously, these were run directly from the respective
workflow files.
The new approach allows us to move the logic to run this only when
workflow files changed from the pull_request trigger into a job. This
has the advantage that older jobs are cleaned up, when the PR changes
from a state of "workflow files changed" to "no workflow files changed".
This can happen when changing a PR's base from staging to master, in
which case changes from master would temporarily appear in the PR as
changes. When these include changes to workflow files, this would
trigger the PR workflow via `pull_request`. Once the base is changed,
the PR is closed and re-opened, so CI runs again - but since it's on the
same commit and the new run doesn't trigger `pull_request`, the results
of the previous run are still kept and displayed. These results may
include cancelled or failed jobs, which are impossible to recover from
without another force-push.
Checking this condition at run-time is only possible, because we move it
into a separate workflow, turning the `pr.yml` workflow into a re-usable
workflow. This will make sure to skip the whole workflow at once, when
no change was detected, which will prevent the "no PR failures" job from
appearing as skipped - which would imply "success" and make the PR
mergeable immediately. Instead the "no PR failures" job is not shown at
all for this trigger, which is generally what we want.
Do the same for `push.yml` for consistency.
(cherry picked from commit 443f30f811)
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.