commit
3723de4b0c
GPG Key ID:
90734A9E619C8A6C
@ -0,0 +1,32 @@ |
||||
# This file contains a list of commits that are not likely what you |
||||
# are looking for in a blame, such as mass reformatting or renaming. |
||||
# You can set this file as a default ignore file for blame by running |
||||
# the following command. |
||||
# |
||||
# $ git config blame.ignoreRevsFile .git-blame-ignore-revs |
||||
# |
||||
# To temporarily not use this file add |
||||
# --ignore-revs-file="" |
||||
# to your blame command. |
||||
# |
||||
# The ignoreRevsFile can't be set globally due to blame failing if the file isn't present. |
||||
# To not have to set the option in every repository it is needed in, |
||||
# save the following script in your path with the name "git-bblame" |
||||
# now you can run |
||||
# $ git bblame $FILE |
||||
# to use the .git-blame-ignore-revs file if it is present. |
||||
# |
||||
# #!/usr/bin/env bash |
||||
# repo_root=$(git rev-parse --show-toplevel) |
||||
# if [[ -e $repo_root/.git-blame-ignore-revs ]]; then |
||||
# git blame --ignore-revs-file="$repo_root/.git-blame-ignore-revs" $@ |
||||
# else |
||||
# git blame $@ |
||||
# fi |
||||
|
||||
|
||||
# nixos/modules/rename: Sort alphabetically |
||||
1f71224fe86605ef4cd23ed327b3da7882dad382 |
||||
|
||||
# nixos: fix module paths in rename.nix |
||||
d08ede042b74b8199dc748323768227b88efcf7c |
||||
@ -1,64 +0,0 @@ |
||||
# How to contribute |
||||
|
||||
Note: contributing implies licensing those contributions |
||||
under the terms of [COPYING](../COPYING), which is an MIT-like license. |
||||
|
||||
## Opening issues |
||||
|
||||
* Make sure you have a [GitHub account](https://github.com/signup/free) |
||||
* Make sure there is no open issue on the topic |
||||
* [Submit a new issue](https://github.com/NixOS/nixpkgs/issues/new/choose) by choosing the kind of topic and fill out the template |
||||
|
||||
## Submitting changes |
||||
|
||||
* Format the commit messages in the following way: |
||||
|
||||
``` |
||||
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc) |
||||
|
||||
(Motivation for change. Additional information.) |
||||
``` |
||||
|
||||
For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message). |
||||
|
||||
Examples: |
||||
|
||||
* nginx: init at 2.0.1 |
||||
* firefox: 54.0.1 -> 55.0 |
||||
* nixos/hydra: add bazBaz option |
||||
|
||||
Dual baz behavior is needed to do foo. |
||||
* nixos/nginx: refactor config generation |
||||
|
||||
The old config generation system used impure shell scripts and could break in specific circumstances (see #1234). |
||||
|
||||
* `meta.description` should: |
||||
* Be capitalized. |
||||
* Not start with the package name. |
||||
* Not have a period at the end. |
||||
* `meta.license` must be set and fit the upstream license. |
||||
* If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`. |
||||
* `meta.maintainers` must be set. |
||||
|
||||
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes) and on how to [submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes). |
||||
|
||||
## Writing good commit messages |
||||
|
||||
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work. |
||||
|
||||
For package version upgrades and such a one-line commit message is usually sufficient. |
||||
|
||||
## Backporting changes |
||||
|
||||
Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches). |
||||
|
||||
1. Take note of the commits in which the change was introduced into `master` branch. |
||||
2. Check out the target _release branch_, e.g. `release-20.09`. Do not use a _channel branch_ like `nixos-20.09` or `nixpkgs-20.09`. |
||||
3. Create a branch for your change, e.g. `git checkout -b backport`. |
||||
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request. |
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-20.09`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[20.09]`. |
||||
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier. |
||||
|
||||
## Reviewing contributions |
||||
|
||||
See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#chap-reviewing-contributions). |
||||
@ -0,0 +1,34 @@ |
||||
--- |
||||
name: Build failure |
||||
about: Create a report to help us improve |
||||
title: '' |
||||
labels: '0.kind: build failure' |
||||
assignees: '' |
||||
|
||||
--- |
||||
|
||||
### Steps To Reproduce |
||||
Steps to reproduce the behavior: |
||||
1. build *X* |
||||
|
||||
### Build log |
||||
``` |
||||
log here if short otherwise a link to a gist |
||||
``` |
||||
|
||||
### Additional context |
||||
Add any other context about the problem here. |
||||
|
||||
### Notify maintainers |
||||
<!-- |
||||
Please @ people who are in the `meta.maintainers` list of the offending package or module. |
||||
If in doubt, check `git blame` for whoever last touched something. |
||||
--> |
||||
|
||||
### Metadata |
||||
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result. |
||||
|
||||
```console |
||||
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m" |
||||
output here |
||||
``` |
||||
@ -0,0 +1,35 @@ |
||||
name: Backport |
||||
on: |
||||
pull_request_target: |
||||
types: [closed, labeled] |
||||
|
||||
# WARNING: |
||||
# When extending this action, be aware that $GITHUB_TOKEN allows write access to |
||||
# the GitHub repository. This means that it should not evaluate user input in a |
||||
# way that allows code injection. |
||||
|
||||
jobs: |
||||
backport: |
||||
name: Backport Pull Request |
||||
if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name)) |
||||
runs-on: ubuntu-latest |
||||
steps: |
||||
- uses: actions/checkout@v3 |
||||
with: |
||||
# required to find all branches |
||||
fetch-depth: 0 |
||||
ref: ${{ github.event.pull_request.head.sha }} |
||||
- name: Create backport PRs |
||||
# should be kept in sync with `version` |
||||
uses: zeebe-io/backport-action@v0.0.5 |
||||
with: |
||||
# Config README: https://github.com/zeebe-io/backport-action#backport-action |
||||
github_token: ${{ secrets.GITHUB_TOKEN }} |
||||
github_workspace: ${{ github.workspace }} |
||||
# should be kept in sync with `uses` |
||||
version: v0.0.5 |
||||
pull_description: |- |
||||
Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}. |
||||
|
||||
* [ ] Before merging, ensure that this backport complies with the [Criteria for Backporting](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#criteria-for-backporting-changes). |
||||
* Even as a non-commiter, if you find that it does not comply, leave a comment. |
||||
@ -0,0 +1,26 @@ |
||||
name: Basic evaluation checks |
||||
|
||||
on: |
||||
workflow_dispatch |
||||
# pull_request: |
||||
# branches: |
||||
# - master |
||||
# - release-** |
||||
# push: |
||||
# branches: |
||||
# - master |
||||
# - release-** |
||||
jobs: |
||||
tests: |
||||
runs-on: ubuntu-latest |
||||
# we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback |
||||
steps: |
||||
- uses: actions/checkout@v3 |
||||
- uses: cachix/install-nix-action@v17 |
||||
- uses: cachix/cachix-action@v10 |
||||
with: |
||||
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere. |
||||
name: nixpkgs-ci |
||||
signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}' |
||||
# explicit list of supportedSystems is needed until aarch64-darwin becomes part of the trunk jobset |
||||
- run: nix-build pkgs/top-level/release.nix -A tarball.nixpkgs-basic-release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin" ]' |
||||
@ -1,41 +0,0 @@ |
||||
name: "merge staging(-next)" |
||||
|
||||
on: |
||||
schedule: |
||||
# * is a special character in YAML so you have to quote this string |
||||
# Merge every 6 hours |
||||
- cron: '0 */6 * * *' |
||||
|
||||
jobs: |
||||
sync-branch: |
||||
if: github.repository == 'NixOS/nixpkgs' |
||||
runs-on: ubuntu-latest |
||||
steps: |
||||
- uses: actions/checkout@v2 |
||||
|
||||
- name: Merge master into staging-next |
||||
id: staging_next |
||||
uses: devmasx/merge-branch@v1.3.1 |
||||
with: |
||||
type: now |
||||
from_branch: master |
||||
target_branch: staging-next |
||||
github_token: ${{ secrets.GITHUB_TOKEN }} |
||||
|
||||
- name: Merge staging-next into staging |
||||
id: staging |
||||
uses: devmasx/merge-branch@v1.3.1 |
||||
with: |
||||
type: now |
||||
from_branch: staging-next |
||||
target_branch: staging |
||||
github_token: ${{ secrets.GITHUB_TOKEN }} |
||||
|
||||
- name: Comment on failure |
||||
uses: peter-evans/create-or-update-comment@v1 |
||||
if: ${{ failure() }} |
||||
with: |
||||
issue-number: 105153 |
||||
body: | |
||||
An automatic merge${{ (steps.staging_next.outcome == 'failure' && ' from master to staging-next') || ((steps.staging.outcome == 'failure' && ' from staging-next to staging') || '') }} [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}). |
||||
|
||||
@ -0,0 +1,26 @@ |
||||
name: NixOS manual checks |
||||
|
||||
permissions: read-all |
||||
|
||||
on: |
||||
pull_request_target: |
||||
branches-ignore: |
||||
- 'release-**' |
||||
paths: |
||||
- 'nixos/**/*.xml' |
||||
- 'nixos/**/*.md' |
||||
|
||||
jobs: |
||||
tests: |
||||
runs-on: ubuntu-latest |
||||
if: github.repository_owner == 'NixOS' |
||||
steps: |
||||
- uses: actions/checkout@v3 |
||||
with: |
||||
# pull_request_target checks out the base branch by default |
||||
ref: refs/pull/${{ github.event.pull_request.number }}/merge |
||||
- uses: cachix/install-nix-action@v17 |
||||
- name: Check DocBook files generated from Markdown are consistent |
||||
run: | |
||||
nixos/doc/manual/md-to-db.sh |
||||
git diff --exit-code |
||||
@ -0,0 +1,21 @@ |
||||
name: "No channel PR" |
||||
|
||||
on: |
||||
pull_request: |
||||
branches: |
||||
- 'nixos-**' |
||||
- 'nixpkgs-**' |
||||
|
||||
jobs: |
||||
fail: |
||||
name: "This PR is is targeting a channel branch" |
||||
runs-on: ubuntu-latest |
||||
steps: |
||||
- run: | |
||||
cat <<EOF |
||||
The nixos-* and nixpkgs-* branches are pushed to by the channel |
||||
release script and should not be merged into directly. |
||||
|
||||
Please target the equivalent release-* branch or master instead. |
||||
EOF |
||||
exit 1 |
||||
@ -0,0 +1,57 @@ |
||||
# This action periodically merges base branches into staging branches. |
||||
# This is done to |
||||
# * prevent conflicts or rather resolve them early |
||||
# * make all potential breakage happen on the staging branch |
||||
# * and make sure that all major rebuilds happen before the staging |
||||
# branch get’s merged back into its base branch. |
||||
|
||||
name: "Periodic Merges (24h)" |
||||
|
||||
|
||||
on: |
||||
schedule: |
||||
# * is a special character in YAML so you have to quote this string |
||||
# Merge every 24 hours |
||||
- cron: '0 0 * * *' |
||||
|
||||
jobs: |
||||
periodic-merge: |
||||
if: github.repository_owner == 'NixOS' |
||||
runs-on: ubuntu-latest |
||||
strategy: |
||||
# don't fail fast, so that all pairs are tried |
||||
fail-fast: false |
||||
# certain branches need to be merged in order, like master->staging-next->staging |
||||
# and disabling parallelism ensures the order of the pairs below. |
||||
max-parallel: 1 |
||||
matrix: |
||||
pairs: |
||||
- from: master |
||||
into: haskell-updates |
||||
- from: release-21.11 |
||||
into: staging-next-21.11 |
||||
- from: staging-next-21.11 |
||||
into: staging-21.11 |
||||
- from: release-22.05 |
||||
into: staging-next-22.05 |
||||
- from: staging-next-22.05 |
||||
into: staging-22.05 |
||||
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }} |
||||
steps: |
||||
- uses: actions/checkout@v3 |
||||
|
||||
- name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }} |
||||
uses: devmasx/merge-branch@1.4.0 |
||||
with: |
||||
type: now |
||||
from_branch: ${{ matrix.pairs.from }} |
||||
target_branch: ${{ matrix.pairs.into }} |
||||
github_token: ${{ secrets.GITHUB_TOKEN }} |
||||
|
||||
- name: Comment on failure |
||||
uses: peter-evans/create-or-update-comment@v2 |
||||
if: ${{ failure() }} |
||||
with: |
||||
issue-number: 105153 |
||||
body: | |
||||
Periodic merge from `${{ matrix.pairs.from }}` into `${{ matrix.pairs.into }}` has [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}). |
||||
@ -0,0 +1,51 @@ |
||||
# This action periodically merges base branches into staging branches. |
||||
# This is done to |
||||
# * prevent conflicts or rather resolve them early |
||||
# * make all potential breakage happen on the staging branch |
||||
# * and make sure that all major rebuilds happen before the staging |
||||
# branch get’s merged back into its base branch. |
||||
|
||||
name: "Periodic Merges (6h)" |
||||
|
||||
|
||||
on: |
||||
schedule: |
||||
# * is a special character in YAML so you have to quote this string |
||||
# Merge every 6 hours |
||||
- cron: '0 */6 * * *' |
||||
|
||||
jobs: |
||||
periodic-merge: |
||||
if: github.repository_owner == 'NixOS' |
||||
runs-on: ubuntu-latest |
||||
strategy: |
||||
# don't fail fast, so that all pairs are tried |
||||
fail-fast: false |
||||
# certain branches need to be merged in order, like master->staging-next->staging |
||||
# and disabling parallelism ensures the order of the pairs below. |
||||
max-parallel: 1 |
||||
matrix: |
||||
pairs: |
||||
- from: master |
||||
into: staging-next |
||||
- from: staging-next |
||||
into: staging |
||||
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }} |
||||
steps: |
||||
- uses: actions/checkout@v3 |
||||
|
||||
- name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }} |
||||
uses: devmasx/merge-branch@1.4.0 |
||||
with: |
||||
type: now |
||||
from_branch: ${{ matrix.pairs.from }} |
||||
target_branch: ${{ matrix.pairs.into }} |
||||
github_token: ${{ secrets.GITHUB_TOKEN }} |
||||
|
||||
- name: Comment on failure |
||||
uses: peter-evans/create-or-update-comment@v2 |
||||
if: ${{ failure() }} |
||||
with: |
||||
issue-number: 105153 |
||||
body: | |
||||
Periodic merge from `${{ matrix.pairs.from }}` into `${{ matrix.pairs.into }}` has [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}). |
||||
@ -1,134 +0,0 @@ |
||||
on: |
||||
issue_comment: |
||||
types: |
||||
- created |
||||
|
||||
# This action allows people with write access to the repo to rebase a PRs base branch |
||||
# by commenting `/rebase ${branch}` on the PR while avoiding CODEOWNER notifications. |
||||
|
||||
jobs: |
||||
rebase: |
||||
runs-on: ubuntu-latest |
||||
if: github.repository_owner == 'NixOS' && github.event.issue.pull_request != '' && contains(github.event.comment.body, '/rebase') |
||||
steps: |
||||
- uses: peter-evans/create-or-update-comment@v1 |
||||
with: |
||||
comment-id: ${{ github.event.comment.id }} |
||||
reactions: eyes |
||||
- uses: scherermichael-oss/action-has-permission@1.0.6 |
||||
id: check-write-access |
||||
with: |
||||
required-permission: write |
||||
env: |
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
||||
- name: check permissions |
||||
run: | |
||||
echo "Commenter doesn't have write access to the repo" |
||||
exit 1 |
||||
if: "! steps.check-write-access.outputs.has-permission" |
||||
- name: setup |
||||
run: | |
||||
curl "https://api.github.com/repos/${{ github.repository }}/pulls/${{ github.event.issue.number }}" 2>/dev/null >pr.json |
||||
cat <<EOF >>"$GITHUB_ENV" |
||||
CAN_MODIFY=$(jq -r '.maintainer_can_modify' pr.json) |
||||
COMMITS=$(jq -r '.commits' pr.json) |
||||
CURRENT_BASE=$(jq -r '.base.ref' pr.json) |
||||
PR_BRANCH=$(jq -r '.head.ref' pr.json) |
||||
COMMENT_BRANCH=$(echo ${{ github.event.comment.body }} | awk "/^\/rebase / {print \$2}") |
||||
PULL_REQUEST=${{ github.event.issue.number }} |
||||
EOF |
||||
rm pr.json |
||||
- name: check branch |
||||
env: |
||||
PERMANENT_BRANCHES: "haskell-updates|master|nixos|nixpkgs|python-unstable|release|staging" |
||||
VALID_BRANCHES: "haskell-updates|master|python-unstable|release-20.09|staging|staging-20.09|staging-next" |
||||
run: | |
||||
message() { |
||||
cat <<EOF |
||||
Can't rebase $PR_BRANCH from $CURRENT_BASE onto $COMMENT_BRANCH (PR:$PULL_REQUEST COMMITS:$COMMITS) |
||||
EOF |
||||
} |
||||
if ! [[ "$COMMENT_BRANCH" =~ ^($VALID_BRANCHES)$ ]]; then |
||||
cat <<EOF |
||||
Check that the branch from the comment is valid: |
||||
|
||||
$(message) |
||||
|
||||
This action can only rebase onto these branches: |
||||
|
||||
$VALID_BRANCHES |
||||
|
||||
\`/rebase \${branch}\` must be at the start of the line |
||||
EOF |
||||
exit 1 |
||||
fi |
||||
if [[ "$COMMENT_BRANCH" == "$CURRENT_BASE" ]]; then |
||||
cat <<EOF |
||||
Check that the branch from the comment isn't the current base branch: |
||||
|
||||
$(message) |
||||
EOF |
||||
exit 1 |
||||
fi |
||||
if [[ "$COMMENT_BRANCH" == "$PR_BRANCH" ]]; then |
||||
cat <<EOF |
||||
Check that the branch from the comment isn't the current branch: |
||||
|
||||
$(message) |
||||
EOF |
||||
exit 1 |
||||
fi |
||||
if [[ "$PR_BRANCH" =~ ^($PERMANENT_BRANCHES) ]]; then |
||||
cat <<EOF |
||||
Check that the PR branch isn't a permanent branch: |
||||
|
||||
$(message) |
||||
EOF |
||||
exit 1 |
||||
fi |
||||
if [[ "$CAN_MODIFY" != "true" ]]; then |
||||
cat <<EOF |
||||
Check that maintainers can edit the PR branch: |
||||
|
||||
$(message) |
||||
EOF |
||||
exit 1 |
||||
fi |
||||
- uses: actions/checkout@v2 |
||||
with: |
||||
fetch-depth: 0 |
||||
- name: rebase pull request |
||||
env: |
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
||||
run: | |
||||
git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com" |
||||
git config --global user.name "github-actions[bot]" |
||||
git fetch origin |
||||
gh pr checkout "$PULL_REQUEST" |
||||
git rebase \ |
||||
--onto="$(git merge-base origin/"$CURRENT_BASE" origin/"$COMMENT_BRANCH")" \ |
||||
"HEAD~$COMMITS" |
||||
git push --force |
||||
curl \ |
||||
-X POST \ |
||||
-H "Accept: application/vnd.github.v3+json" \ |
||||
-H "Authorization: token $GITHUB_TOKEN" \ |
||||
-d "{ \"base\": \"$COMMENT_BRANCH\" }" \ |
||||
"https://api.github.com/repos/${{ github.repository }}/pulls/$PULL_REQUEST" |
||||
curl \ |
||||
-X PATCH \ |
||||
-H "Accept: application/vnd.github.v3+json" \ |
||||
-H "Authorization: token $GITHUB_TOKEN" \ |
||||
-d '{ "state": "closed" }' \ |
||||
"https://api.github.com/repos/${{ github.repository }}/pulls/$PULL_REQUEST" |
||||
- uses: peter-evans/create-or-update-comment@v1 |
||||
with: |
||||
issue-number: ${{ github.event.issue.number }} |
||||
body: | |
||||
Rebased, please reopen the pull request to restart CI |
||||
- uses: peter-evans/create-or-update-comment@v1 |
||||
if: failure() |
||||
with: |
||||
issue-number: ${{ github.event.issue.number }} |
||||
body: | |
||||
[Failed to rebase](https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}) |
||||
@ -0,0 +1,48 @@ |
||||
name: "Update terraform-providers" |
||||
|
||||
on: |
||||
schedule: |
||||
- cron: "14 3 * * 1" |
||||
workflow_dispatch: |
||||
|
||||
jobs: |
||||
tf-providers: |
||||
if: github.repository_owner == 'NixOS' && github.ref == 'refs/heads/master' # ensure workflow_dispatch only runs on master |
||||
runs-on: ubuntu-latest |
||||
steps: |
||||
- uses: actions/checkout@v3 |
||||
- uses: cachix/install-nix-action@v17 |
||||
- name: setup |
||||
id: setup |
||||
run: | |
||||
echo ::set-output name=title::"terraform-providers: update $(date -u +"%Y-%m-%d")" |
||||
- name: update terraform-providers |
||||
run: | |
||||
git config user.email "41898282+github-actions[bot]@users.noreply.github.com" |
||||
git config user.name "github-actions[bot]" |
||||
pushd pkgs/applications/networking/cluster/terraform-providers |
||||
./update-all-providers --no-build |
||||
git commit -m "${{ steps.setup.outputs.title }}" providers.json |
||||
popd |
||||
- name: create PR |
||||
uses: peter-evans/create-pull-request@v4 |
||||
with: |
||||
body: | |
||||
Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action. |
||||
|
||||
Check that all providers build with: |
||||
``` |
||||
@ofborg build terraform-full |
||||
``` |
||||
branch: terraform-providers-update |
||||
delete-branch: false |
||||
labels: "2.status: work-in-progress" |
||||
title: ${{ steps.setup.outputs.title }} |
||||
token: ${{ secrets.GITHUB_TOKEN }} |
||||
- name: comment on failure |
||||
uses: peter-evans/create-or-update-comment@v2 |
||||
if: ${{ failure() }} |
||||
with: |
||||
issue-number: 153416 |
||||
body: | |
||||
Automatic update of terraform providers [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}). |
||||
@ -1 +1 @@ |
||||
21.05 |
||||
22.05 |
||||
|
||||
@ -0,0 +1,134 @@ |
||||
# How to contribute |
||||
|
||||
Note: contributing implies licensing those contributions |
||||
under the terms of [COPYING](COPYING), which is an MIT-like license. |
||||
|
||||
## Opening issues |
||||
|
||||
* Make sure you have a [GitHub account](https://github.com/signup/free) |
||||
* Make sure there is no open issue on the topic |
||||
* [Submit a new issue](https://github.com/NixOS/nixpkgs/issues/new/choose) by choosing the kind of topic and fill out the template |
||||
|
||||
## Submitting changes |
||||
|
||||
Read the ["Submitting changes"](https://nixos.org/nixpkgs/manual/#chap-submitting-changes) section of the nixpkgs manual. It explains how to write, test, and iterate on your change, and which branch to base your pull request against. |
||||
|
||||
Below is a short excerpt of some points in there: |
||||
|
||||
* Format the commit messages in the following way: |
||||
|
||||
``` |
||||
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc) |
||||
|
||||
(Motivation for change. Link to release notes. Additional information.) |
||||
``` |
||||
|
||||
For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message). |
||||
|
||||
Examples: |
||||
|
||||
* nginx: init at 2.0.1 |
||||
* firefox: 54.0.1 -> 55.0 |
||||
https://www.mozilla.org/en-US/firefox/55.0/releasenotes/ |
||||
* nixos/hydra: add bazBaz option |
||||
|
||||
Dual baz behavior is needed to do foo. |
||||
* nixos/nginx: refactor config generation |
||||
|
||||
The old config generation system used impure shell scripts and could break in specific circumstances (see #1234). |
||||
|
||||
* `meta.description` should: |
||||
* Be capitalized. |
||||
* Not start with the package name. |
||||
* Not have a period at the end. |
||||
* `meta.license` must be set and fit the upstream license. |
||||
* If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`. |
||||
* `meta.maintainers` must be set. |
||||
|
||||
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes). |
||||
|
||||
## Writing good commit messages |
||||
|
||||
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work. |
||||
|
||||
For package version upgrades and such a one-line commit message is usually sufficient. |
||||
|
||||
## Rebasing between branches (i.e. from master to staging) |
||||
|
||||
From time to time, changes between branches must be rebased, for example, if the |
||||
number of new rebuilds they would cause is too large for the target branch. When |
||||
rebasing, care must be taken to include only the intended changes, otherwise |
||||
many CODEOWNERS will be inadvertently requested for review. To achieve this, |
||||
rebasing should not be performed directly on the target branch, but on the merge |
||||
base between the current and target branch. |
||||
|
||||
In the following example, we see a rebase from `master` onto the merge base |
||||
between `master` and `staging`, so that a change can eventually be retargeted to |
||||
`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git` |
||||
while the `origin` remote is used for the remote you are pushing to. |
||||
|
||||
|
||||
```console |
||||
# Find the common base between two branches |
||||
common=$(git merge-base upstream/master upstream/staging) |
||||
# Find the common base between your feature branch and master |
||||
commits=$(git merge-base $(git branch --show-current) upstream/master) |
||||
# Rebase all commits onto the common base |
||||
git rebase --onto=$common $commits |
||||
# Force push your changes |
||||
git push origin $(git branch --show-current) --force-with-lease |
||||
``` |
||||
|
||||
Then change the base branch in the GitHub PR using the *Edit* button in the upper |
||||
right corner, and switch from `master` to `staging`. After the PR has been |
||||
retargeted it might be necessary to do a final rebase onto the target branch, to |
||||
resolve any outstanding merge conflicts. |
||||
|
||||
```console |
||||
# Rebase onto target branch |
||||
git rebase upstream/staging |
||||
# Review and fixup possible conflicts |
||||
git status |
||||
# Force push your changes |
||||
git push origin $(git branch --show-current) --force-with-lease |
||||
``` |
||||
|
||||
## Backporting changes |
||||
|
||||
Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches). |
||||
|
||||
You can add a label such as `backport release-22.05` to a PR, so that merging it will |
||||
automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)). |
||||
This also works for PR's that have already been merged, and might take a couple of minutes to trigger. |
||||
|
||||
You can also create the backport manually: |
||||
|
||||
1. Take note of the commits in which the change was introduced into `master` branch. |
||||
2. Check out the target _release branch_, e.g. `release-22.05`. Do not use a _channel branch_ like `nixos-22.05` or `nixpkgs-22.05-darwin`. |
||||
3. Create a branch for your change, e.g. `git checkout -b backport`. |
||||
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request. |
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.05`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.05]`. |
||||
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier. |
||||
|
||||
## Criteria for Backporting changes |
||||
|
||||
Anything that does not cause user or downstream dependency regressions can be backported. This includes: |
||||
- New Packages / Modules |
||||
- Security / Patch updates |
||||
- Version updates which include new functionality (but no breaking changes) |
||||
- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`) |
||||
- Security critical applications (E.g. `firefox`) |
||||
|
||||
## Generating 22.11 Release Notes |
||||
|
||||
Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document. |
||||
|
||||
Steps for updating 22.11 Release notes: |
||||
|
||||
1. Edit `nixos/doc/manual/release-notes/rl-2211.section.md` with the desired changes |
||||
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2211.section.xml` |
||||
3. Include changes to `rl-2211.section.md` and `rl-2211.section.xml` in the same commit. |
||||
|
||||
## Reviewing contributions |
||||
|
||||
See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#chap-reviewing-contributions). |
||||
@ -0,0 +1,23 @@ |
||||
--[[ |
||||
Converts Code AST nodes produced by pandoc’s DocBook reader |
||||
from citerefentry elements into AST for corresponding role |
||||
for reStructuredText. |
||||
|
||||
We use subset of MyST syntax (CommonMark with features from rST) |
||||
so let’s use the rST AST for rST features. |
||||
|
||||
Reference: https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage |
||||
]] |
||||
|
||||
function Code(elem) |
||||
elem.classes = elem.classes:map(function (x) |
||||
if x == 'citerefentry' then |
||||
elem.attributes['role'] = 'manpage' |
||||
return 'interpreted-text' |
||||
else |
||||
return x |
||||
end |
||||
end) |
||||
|
||||
return elem |
||||
end |
||||
@ -0,0 +1,34 @@ |
||||
--[[ |
||||
Converts Link AST nodes with empty label to DocBook xref elements. |
||||
|
||||
This is a temporary script to be able use cross-references conveniently |
||||
using syntax taken from MyST, while we still use docbook-xsl |
||||
for generating the documentation. |
||||
|
||||
Reference: https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing |
||||
]] |
||||
|
||||
local function starts_with(start, str) |
||||
return str:sub(1, #start) == start |
||||
end |
||||
|
||||
local function escape_xml_arg(arg) |
||||
amps = arg:gsub('&', '&') |
||||
amps_quotes = amps:gsub('"', '"') |
||||
amps_quotes_lt = amps_quotes:gsub('<', '<') |
||||
|
||||
return amps_quotes_lt |
||||
end |
||||
|
||||
function Link(elem) |
||||
has_no_content = #elem.content == 0 |
||||
targets_anchor = starts_with('#', elem.target) |
||||
has_no_attributes = elem.title == '' and elem.identifier == '' and #elem.classes == 0 and #elem.attributes == 0 |
||||
|
||||
if has_no_content and targets_anchor and has_no_attributes then |
||||
-- xref expects idref without the pound-sign |
||||
target_without_hash = elem.target:sub(2, #elem.target) |
||||
|
||||
return pandoc.RawInline('docbook', '<xref linkend="' .. escape_xml_arg(target_without_hash) .. '" />') |
||||
end |
||||
end |
||||
@ -0,0 +1,36 @@ |
||||
--[[ |
||||
Converts AST for reStructuredText roles into corresponding |
||||
DocBook elements. |
||||
|
||||
Currently, only a subset of roles is supported. |
||||
|
||||
Reference: |
||||
List of roles: |
||||
https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html |
||||
manpage: |
||||
https://tdg.docbook.org/tdg/5.1/citerefentry.html |
||||
file: |
||||
https://tdg.docbook.org/tdg/5.1/filename.html |
||||
]] |
||||
|
||||
function Code(elem) |
||||
if elem.classes:includes('interpreted-text') then |
||||
local tag = nil |
||||
local content = elem.text |
||||
if elem.attributes['role'] == 'manpage' then |
||||
tag = 'citerefentry' |
||||
local title, volnum = content:match('^(.+)%((%w+)%)$') |
||||
if title == nil then |
||||
-- No volnum in parentheses. |
||||
title = content |
||||
end |
||||
content = '<refentrytitle>' .. title .. '</refentrytitle>' .. (volnum ~= nil and ('<manvolnum>' .. volnum .. '</manvolnum>') or '') |
||||
elseif elem.attributes['role'] == 'file' then |
||||
tag = 'filename' |
||||
end |
||||
|
||||
if tag ~= nil then |
||||
return pandoc.RawInline('docbook', '<' .. tag .. '>' .. content .. '</' .. tag .. '>') |
||||
end |
||||
end |
||||
end |
||||
@ -0,0 +1,17 @@ |
||||
--[[ |
||||
Turns a manpage reference into a link, when a mapping is defined below. |
||||
]] |
||||
|
||||
local man_urls = { |
||||
["tmpfiles.d(5)"] = "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html", |
||||
["nix.conf(5)"] = "https://nixos.org/manual/nix/stable/#sec-conf-file", |
||||
["systemd.time(7)"] = "https://www.freedesktop.org/software/systemd/man/systemd.time.html", |
||||
["systemd.timer(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.timer.html", |
||||
} |
||||
|
||||
function Code(elem) |
||||
local is_man_role = elem.classes:includes('interpreted-text') and elem.attributes['role'] == 'manpage' |
||||
if is_man_role and man_urls[elem.text] ~= nil then |
||||
return pandoc.Link(elem, man_urls[elem.text]) |
||||
end |
||||
end |
||||
@ -0,0 +1,29 @@ |
||||
--[[ |
||||
Replaces Str AST nodes containing {role}, followed by a Code node |
||||
by a Code node with attrs that would be produced by rST reader |
||||
from the role syntax. |
||||
|
||||
This is to emulate MyST syntax in Pandoc. |
||||
(MyST is a CommonMark flavour with rST features mixed in.) |
||||
|
||||
Reference: https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point |
||||
]] |
||||
|
||||
function Inlines(inlines) |
||||
for i = #inlines-1,1,-1 do |
||||
local first = inlines[i] |
||||
local second = inlines[i+1] |
||||
local correct_tags = first.tag == 'Str' and second.tag == 'Code' |
||||
if correct_tags then |
||||
-- docutils supports alphanumeric strings separated by [-._:] |
||||
-- We are slightly more liberal for simplicity. |
||||
local role = first.text:match('^{([-._+:%w]+)}$') |
||||
if role ~= nil then |
||||
inlines:remove(i) |
||||
second.attributes['role'] = role |
||||
second.classes:insert('interpreted-text') |
||||
end |
||||
end |
||||
end |
||||
return inlines |
||||
end |
||||
@ -0,0 +1,25 @@ |
||||
--[[ |
||||
Replaces Code nodes with attrs that would be produced by rST reader |
||||
from the role syntax by a Str AST node containing {role}, followed by a Code node. |
||||
|
||||
This is to emulate MyST syntax in Pandoc. |
||||
(MyST is a CommonMark flavour with rST features mixed in.) |
||||
|
||||
Reference: https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point |
||||
]] |
||||
|
||||
function Code(elem) |
||||
local role = elem.attributes['role'] |
||||
|
||||
if elem.classes:includes('interpreted-text') and role ~= nil then |
||||
elem.classes = elem.classes:filter(function (c) |
||||
return c ~= 'interpreted-text' |
||||
end) |
||||
elem.attributes['role'] = nil |
||||
|
||||
return { |
||||
pandoc.Str('{' .. role .. '}'), |
||||
elem, |
||||
} |
||||
end |
||||
end |
||||
@ -1,11 +1,11 @@ |
||||
# Elm {#sec-elm} |
||||
|
||||
To start a development environment do |
||||
To start a development environment, run: |
||||
|
||||
```ShellSession |
||||
nix-shell -p elmPackages.elm elmPackages.elm-format |
||||
``` |
||||
|
||||
To update the Elm compiler, see <filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>. |
||||
To update the Elm compiler, see `nixpkgs/pkgs/development/compilers/elm/README.md`. |
||||
|
||||
To package Elm applications, [read about elm2nix](https://github.com/hercules-ci/elm2nix#elm2nix). |
||||
|
||||
@ -0,0 +1,18 @@ |
||||
# /etc files {#etc} |
||||
|
||||
Certain calls in glibc require access to runtime files found in `/etc` such as `/etc/protocols` or `/etc/services` -- [getprotobyname](https://linux.die.net/man/3/getprotobyname) is one such function. |
||||
|
||||
On non-NixOS distributions these files are typically provided by packages (i.e., [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present. |
||||
|
||||
If [iana-etc](https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.iana-etc.x86_64-linux) is part of your `buildInputs`, then it will set the environment variables `NIX_ETC_PROTOCOLS` and `NIX_ETC_SERVICES` to the corresponding files in the package through a setup hook. |
||||
|
||||
|
||||
```bash |
||||
> nix-shell -p iana-etc |
||||
|
||||
[nix-shell:~]$ env | grep NIX_ETC |
||||
NIX_ETC_SERVICES=/nix/store/aj866hr8fad8flnggwdhrldm0g799ccz-iana-etc-20210225/etc/services |
||||
NIX_ETC_PROTOCOLS=/nix/store/aj866hr8fad8flnggwdhrldm0g799ccz-iana-etc-20210225/etc/protocols |
||||
``` |
||||
|
||||
Nixpkg's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variables are *not* set, then it will attempt to find the files at the default location within `/etc`. |
||||
@ -1,5 +1,5 @@ |
||||
# Locales {#locales} |
||||
|
||||
To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable. |
||||
To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats, Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable. |
||||
|
||||
On non-NixOS distributions this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package. |
||||
On non-NixOS distributions, this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package. |
||||
|
||||
@ -1,17 +1,37 @@ |
||||
# pkgs.mkShell {#sec-pkgs-mkShell} |
||||
|
||||
`pkgs.mkShell` is a special kind of derivation that is only useful when using |
||||
it combined with `nix-shell`. It will in fact fail to instantiate when invoked |
||||
with `nix-build`. |
||||
`pkgs.mkShell` is a specialized `stdenv.mkDerivation` that removes some |
||||
repetition when using it with `nix-shell` (or `nix develop`). |
||||
|
||||
## Usage {#sec-pkgs-mkShell-usage} |
||||
|
||||
Here is a common usage example: |
||||
|
||||
```nix |
||||
{ pkgs ? import <nixpkgs> {} }: |
||||
pkgs.mkShell { |
||||
# specify which packages to add to the shell environment |
||||
packages = [ pkgs.gnumake ]; |
||||
# add all the dependencies, of the given packages, to the shell environment |
||||
inputsFrom = with pkgs; [ hello gnutar ]; |
||||
|
||||
inputsFrom = [ pkgs.hello pkgs.gnutar ]; |
||||
|
||||
shellHook = '' |
||||
export DEBUG=1 |
||||
''; |
||||
} |
||||
``` |
||||
|
||||
## Attributes |
||||
|
||||
* `name` (default: `nix-shell`). Set the name of the derivation. |
||||
* `packages` (default: `[]`). Add executable packages to the `nix-shell` environment. |
||||
* `inputsFrom` (default: `[]`). Add build dependencies of the listed derivations to the `nix-shell` environment. |
||||
* `shellHook` (default: `""`). Bash statements that are executed by `nix-shell`. |
||||
|
||||
... all the attributes of `stdenv.mkDerivation`. |
||||
|
||||
## Building the shell |
||||
|
||||
This derivation output will contain a text file that contains a reference to |
||||
all the build inputs. This is useful in CI where we want to make sure that |
||||
every derivation, and its dependencies, build properly. Or when creating a GC |
||||
root so that the build dependencies don't get garbage-collected. |
||||
|
||||
@ -0,0 +1,128 @@ |
||||
# Testers {#chap-testers} |
||||
This chapter describes several testing builders which are available in the <literal>testers</literal> namespace. |
||||
|
||||
## `testVersion` {#tester-testVersion} |
||||
|
||||
Checks the command output contains the specified version |
||||
|
||||
Although simplistic, this test assures that the main program |
||||
can run. While there's no substitute for a real test case, |
||||
it does catch dynamic linking errors and such. It also provides |
||||
some protection against accidentally building the wrong version, |
||||
for example when using an 'old' hash in a fixed-output derivation. |
||||
|
||||
Examples: |
||||
|
||||
```nix |
||||
passthru.tests.version = testVersion { package = hello; }; |
||||
|
||||
passthru.tests.version = testVersion { |
||||
package = seaweedfs; |
||||
command = "weed version"; |
||||
}; |
||||
|
||||
passthru.tests.version = testVersion { |
||||
package = key; |
||||
command = "KeY --help"; |
||||
# Wrong '2.5' version in the code. Drop on next version. |
||||
version = "2.5"; |
||||
}; |
||||
``` |
||||
|
||||
## `testEqualDerivation` {#tester-testEqualDerivation} |
||||
|
||||
Checks that two packages produce the exact same build instructions. |
||||
|
||||
This can be used to make sure that a certain difference of configuration, |
||||
such as the presence of an overlay does not cause a cache miss. |
||||
|
||||
When the derivations are equal, the return value is an empty file. |
||||
Otherwise, the build log explains the difference via `nix-diff`. |
||||
|
||||
Example: |
||||
|
||||
```nix |
||||
testEqualDerivation |
||||
"The hello package must stay the same when enabling checks." |
||||
hello |
||||
(hello.overrideAttrs(o: { doCheck = true; })) |
||||
``` |
||||
|
||||
## `invalidateFetcherByDrvHash` {#tester-invalidateFetcherByDrvHash} |
||||
|
||||
Use the derivation hash to invalidate the output via name, for testing. |
||||
|
||||
Type: `(a@{ name, ... } -> Derivation) -> a -> Derivation` |
||||
|
||||
Normally, fixed output derivations can and should be cached by their output |
||||
hash only, but for testing we want to re-fetch everytime the fetcher changes. |
||||
|
||||
Changes to the fetcher become apparent in the drvPath, which is a hash of |
||||
how to fetch, rather than a fixed store path. |
||||
By inserting this hash into the name, we can make sure to re-run the fetcher |
||||
every time the fetcher changes. |
||||
|
||||
This relies on the assumption that Nix isn't clever enough to reuse its |
||||
database of local store contents to optimize fetching. |
||||
|
||||
You might notice that the "salted" name derives from the normal invocation, |
||||
not the final derivation. `invalidateFetcherByDrvHash` has to invoke the fetcher |
||||
function twice: once to get a derivation hash, and again to produce the final |
||||
fixed output derivation. |
||||
|
||||
Example: |
||||
|
||||
```nix |
||||
tests.fetchgit = invalidateFetcherByDrvHash fetchgit { |
||||
name = "nix-source"; |
||||
url = "https://github.com/NixOS/nix"; |
||||
rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a"; |
||||
sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY="; |
||||
}; |
||||
``` |
||||
|
||||
## `nixosTest` {#tester-nixosTest} |
||||
|
||||
Run a NixOS VM network test using this evaluation of Nixpkgs. |
||||
|
||||
NOTE: This function is primarily for external use. NixOS itself uses `make-test-python.nix` directly. Packages defined in Nixpkgs [reuse NixOS tests via `nixosTests`, plural](#ssec-nixos-tests-linking). |
||||
|
||||
It is mostly equivalent to the function `import ./make-test-python.nix` from the |
||||
[NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), |
||||
except that the current application of Nixpkgs (`pkgs`) will be used, instead of |
||||
letting NixOS invoke Nixpkgs anew. |
||||
|
||||
If a test machine needs to set NixOS options under `nixpkgs`, it must set only the |
||||
`nixpkgs.pkgs` option. |
||||
|
||||
### Parameter |
||||
|
||||
A [NixOS VM test network](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), or path to it. Example: |
||||
|
||||
```nix |
||||
{ |
||||
name = "my-test"; |
||||
nodes = { |
||||
machine1 = { lib, pkgs, nodes, ... }: { |
||||
environment.systemPackages = [ pkgs.hello ]; |
||||
services.foo.enable = true; |
||||
}; |
||||
# machine2 = ...; |
||||
}; |
||||
testScript = '' |
||||
start_all() |
||||
machine1.wait_for_unit("foo.service") |
||||
machine1.succeed("hello | foo-send") |
||||
''; |
||||
} |
||||
``` |
||||
|
||||
### Result |
||||
|
||||
A derivation that runs the VM test. |
||||
|
||||
Notable attributes: |
||||
|
||||
* `nodes`: the evaluated NixOS configurations. Useful for debugging and exploring the configuration. |
||||
|
||||
* `driverInteractive`: a script that launches an interactive Python session in the context of the `testScript`. |
||||
@ -0,0 +1,5 @@ |
||||
# Debugging Nix Expressions {#sec-debug} |
||||
|
||||
Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions. |
||||
|
||||
In the `lib/debug.nix` file you will find a number of functions that help (pretty-)printing values while evaluation is running. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in `lib/debug.nix` for usage information. |
||||
@ -1,14 +0,0 @@ |
||||
<section xmlns="http://docbook.org/ns/docbook" |
||||
xmlns:xlink="http://www.w3.org/1999/xlink" |
||||
xmlns:xi="http://www.w3.org/2001/XInclude" |
||||
xml:id="sec-debug"> |
||||
<title>Debugging Nix Expressions</title> |
||||
|
||||
<para> |
||||
Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions. |
||||
</para> |
||||
|
||||
<para> |
||||
In the <literal>lib/debug.nix</literal> file you will find a number of functions that help (pretty-)printing values while evaluation is runnnig. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in <literal>lib/debug.nix</literal> for usage information. |
||||
</para> |
||||
</section> |
||||
@ -0,0 +1,49 @@ |
||||
# pkgs.nix-gitignore {#sec-pkgs-nix-gitignore} |
||||
|
||||
`pkgs.nix-gitignore` is a function that acts similarly to `builtins.filterSource` but also allows filtering with the help of the gitignore format. |
||||
|
||||
## Usage {#sec-pkgs-nix-gitignore-usage} |
||||
|
||||
`pkgs.nix-gitignore` exports a number of functions, but you\'ll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string. |
||||
|
||||
```nix |
||||
{ pkgs ? import <nixpkgs> {} }: |
||||
|
||||
nix-gitignore.gitignoreSource [] ./source |
||||
# Simplest version |
||||
|
||||
nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source |
||||
# This one reads the ./source/.gitignore and concats the auxiliary ignores |
||||
|
||||
nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source |
||||
# Use this string as gitignore, don't read ./source/.gitignore. |
||||
|
||||
nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n", ~/.gitignore] ./source |
||||
# It also accepts a list (of strings and paths) that will be concatenated |
||||
# once the paths are turned to strings via readFile. |
||||
``` |
||||
|
||||
These functions are derived from the `Filter` functions by setting the first filter argument to `(_: _: true)`: |
||||
|
||||
```nix |
||||
gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true); |
||||
gitignoreSource = gitignoreFilterSource (_: _: true); |
||||
``` |
||||
|
||||
Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it\'s blacklisted by either your filter or the gitignoreFilter. |
||||
|
||||
If you want to make your own filter from scratch, you may use |
||||
|
||||
```nix |
||||
gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root; |
||||
``` |
||||
|
||||
## gitignore files in subdirectories {#sec-pkgs-nix-gitignore-usage-recursive} |
||||
|
||||
If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function: |
||||
|
||||
```nix |
||||
gitignoreFilterRecursiveSource = filter: patterns: root: |
||||
# OR |
||||
gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true); |
||||
``` |
||||
@ -1,70 +0,0 @@ |
||||
<section xmlns="http://docbook.org/ns/docbook" |
||||
xmlns:xlink="http://www.w3.org/1999/xlink" |
||||
xmlns:xi="http://www.w3.org/2001/XInclude" |
||||
xml:id="sec-pkgs-nix-gitignore"> |
||||
<title>pkgs.nix-gitignore</title> |
||||
|
||||
<para> |
||||
<function>pkgs.nix-gitignore</function> is a function that acts similarly to <literal>builtins.filterSource</literal> but also allows filtering with the help of the gitignore format. |
||||
</para> |
||||
|
||||
<section xml:id="sec-pkgs-nix-gitignore-usage"> |
||||
<title>Usage</title> |
||||
|
||||
<para> |
||||
<literal>pkgs.nix-gitignore</literal> exports a number of functions, but you'll most likely need either <literal>gitignoreSource</literal> or <literal>gitignoreSourcePure</literal>. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string. |
||||
</para> |
||||
|
||||
<programlisting><![CDATA[ |
||||
{ pkgs ? import <nixpkgs> {} }: |
||||
|
||||
nix-gitignore.gitignoreSource [] ./source |
||||
# Simplest version |
||||
|
||||
nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source |
||||
# This one reads the ./source/.gitignore and concats the auxiliary ignores |
||||
|
||||
nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source |
||||
# Use this string as gitignore, don't read ./source/.gitignore. |
||||
|
||||
nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n", ~/.gitignore] ./source |
||||
# It also accepts a list (of strings and paths) that will be concatenated |
||||
# once the paths are turned to strings via readFile. |
||||
]]></programlisting> |
||||
|
||||
<para> |
||||
These functions are derived from the <literal>Filter</literal> functions by setting the first filter argument to <literal>(_: _: true)</literal>: |
||||
</para> |
||||
|
||||
<programlisting><![CDATA[ |
||||
gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true); |
||||
gitignoreSource = gitignoreFilterSource (_: _: true); |
||||
]]></programlisting> |
||||
|
||||
<para> |
||||
Those filter functions accept the same arguments the <literal>builtins.filterSource</literal> function would pass to its filters, thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be extensionally equivalent to <literal>filterSource</literal>. The file is blacklisted iff it's blacklisted by either your filter or the gitignoreFilter. |
||||
</para> |
||||
|
||||
<para> |
||||
If you want to make your own filter from scratch, you may use |
||||
</para> |
||||
|
||||
<programlisting><![CDATA[ |
||||
gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root; |
||||
]]></programlisting> |
||||
</section> |
||||
|
||||
<section xml:id="sec-pkgs-nix-gitignore-usage-recursive"> |
||||
<title>gitignore files in subdirectories</title> |
||||
|
||||
<para> |
||||
If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function: |
||||
</para> |
||||
|
||||
<programlisting><![CDATA[ |
||||
gitignoreFilterRecursiveSource = filter: patterns: root: |
||||
# OR |
||||
gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true); |
||||
]]></programlisting> |
||||
</section> |
||||
</section> |
||||
@ -0,0 +1,17 @@ |
||||
# prefer-remote-fetch overlay {#sec-prefer-remote-fetch} |
||||
|
||||
`prefer-remote-fetch` is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay: |
||||
|
||||
```nix |
||||
self: super: |
||||
(super.prefer-remote-fetch self super) |
||||
``` |
||||
|
||||
A full configuration example for that sets the overlay up for your own account, could look like this |
||||
|
||||
```ShellSession |
||||
$ mkdir ~/.config/nixpkgs/overlays/ |
||||
$ cat > ~/.config/nixpkgs/overlays/prefer-remote-fetch.nix <<EOF |
||||
self: super: super.prefer-remote-fetch self super |
||||
EOF |
||||
``` |
||||
@ -1,21 +0,0 @@ |
||||
<section xmlns="http://docbook.org/ns/docbook" |
||||
xmlns:xlink="http://www.w3.org/1999/xlink" |
||||
xmlns:xi="http://www.w3.org/2001/xinclude" |
||||
xml:id="sec-prefer-remote-fetch"> |
||||
<title>prefer-remote-fetch overlay</title> |
||||
|
||||
<para> |
||||
<function>prefer-remote-fetch</function> is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay: |
||||
<programlisting> |
||||
self: super: |
||||
(super.prefer-remote-fetch self super) |
||||
</programlisting> |
||||
A full configuration example for that sets the overlay up for your own account, could look like this |
||||
<screen> |
||||
<prompt>$ </prompt>mkdir ~/.config/nixpkgs/overlays/ |
||||
<prompt>$ </prompt>cat > ~/.config/nixpkgs/overlays/prefer-remote-fetch.nix <<EOF |
||||
self: super: super.prefer-remote-fetch self super |
||||
EOF |
||||
</screen> |
||||
</para> |
||||
</section> |
||||
@ -0,0 +1,10 @@ |
||||
<chapter xmlns="http://docbook.org/ns/docbook" |
||||
xmlns:xlink="http://www.w3.org/1999/xlink" |
||||
xmlns:xi="http://www.w3.org/2001/XInclude" |
||||
xml:id="chap-hooks"> |
||||
<title>Hooks reference</title> |
||||
<para> |
||||
Nixpkgs has several hook packages that augment the stdenv phases. |
||||
</para> |
||||
<xi:include href="./postgresql-test-hook.section.xml" /> |
||||
</chapter> |
||||
@ -0,0 +1,59 @@ |
||||
|
||||
# `postgresqlTestHook` {#sec-postgresqlTestHook} |
||||
|
||||
This hook starts a PostgreSQL server during the `checkPhase`. Example: |
||||
|
||||
```nix |
||||
{ stdenv, postgresql, postgresqlTestHook }: |
||||
stdenv.mkDerivation { |
||||
|
||||
# ... |
||||
|
||||
checkInputs = [ |
||||
postgresql |
||||
postgresqlTestHook |
||||
]; |
||||
} |
||||
``` |
||||
|
||||
If you use a custom `checkPhase`, remember to add the `runHook` calls: |
||||
```nix |
||||
checkPhase '' |
||||
runHook preCheck |
||||
|
||||
# ... your tests |
||||
|
||||
runHook postCheck |
||||
'' |
||||
``` |
||||
|
||||
## Variables {#sec-postgresqlTestHook-variables} |
||||
|
||||
The hook logic will read a number of variables and set them to a default value if unset or empty. |
||||
|
||||
Exported variables: |
||||
|
||||
- `PGDATA`: location of server files. |
||||
- `PGHOST`: location of UNIX domain socket directory; the default `host` in a connection string. |
||||
- `PGUSER`: user to create / log in with, default: `test_user`. |
||||
- `PGDATABASE`: database name, default: `test_db`. |
||||
|
||||
Bash-only variables: |
||||
|
||||
- `postgresqlTestUserOptions`: SQL options to use when creating the `$PGUSER` role, default: `LOGIN`. |
||||
- `postgresqlTestSetupSQL`: SQL commands to run as database administrator after startup, default: statements that create `$PGUSER` and `$PGDATABASE`. |
||||
- `postgresqlTestSetupCommands`: bash commands to run after database start, defaults to running `$postgresqlTestSetupSQL` as database administrator. |
||||
- `postgresqlEnableTCP`: set to `1` to enable TCP listening. Flaky; not recommended. |
||||
- `postgresqlStartCommands`: defaults to `pg_ctl start`. |
||||
|
||||
## TCP and the Nix sandbox {#sec-postgresqlTestHook-tcp} |
||||
|
||||
`postgresqlEnableTCP` relies on network sandboxing, which is not available on macOS and some custom Nix installations, resulting in flaky tests. |
||||
For this reason, it is disabled by default. |
||||
|
||||
The preferred solution is to make the test suite use a UNIX domain socket connection. This is the default behavior when no `host` connection parameter is provided. |
||||
Some test suites hardcode a value for `host` though, so a patch may be required. If you can upstream the patch, you can make `host` default to the `PGHOST` environment variable when set. Otherwise, you can patch it locally to omit the `host` connection string parameter altogether. |
||||
|
||||
::: {.note} |
||||
The error `libpq: failed (could not receive data from server: Connection refused` is generally an indication that the test suite is trying to connect through TCP. |
||||
::: |
||||
@ -0,0 +1,49 @@ |
||||
# CHICKEN {#sec-chicken} |
||||
|
||||
[CHICKEN](https://call-cc.org/) is a |
||||
[R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant Scheme |
||||
compiler. It includes an interactive mode and a custom package format, "eggs". |
||||
|
||||
## Using Eggs |
||||
|
||||
Eggs described in nixpkgs are available inside the |
||||
`chickenPackages.chickenEggs` attrset. Including an egg as a build input is |
||||
done in the typical Nix fashion. For example, to include support for [SRFI |
||||
189](https://srfi.schemers.org/srfi-189/srfi-189.html) in a derivation, one |
||||
might write: |
||||
|
||||
```nix |
||||
buildInputs = [ |
||||
chicken |
||||
chickenPackages.chickenEggs.srfi-189 |
||||
]; |
||||
``` |
||||
|
||||
Both `chicken` and its eggs have a setup hook which configures the environment |
||||
variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`. |
||||
|
||||
## Updating Eggs |
||||
|
||||
nixpkgs only knows about a subset of all published eggs. It uses |
||||
[egg2nix](https://github.com/the-kenny/egg2nix) to generate a |
||||
package set from a list of eggs to include. |
||||
|
||||
The package set is regenerated by running the following shell commands: |
||||
|
||||
``` |
||||
$ nix-shell -p chickenPackages.egg2nix |
||||
$ cd pkgs/development/compilers/chicken/5/ |
||||
$ egg2nix eggs.scm > eggs.nix |
||||
``` |
||||
|
||||
## Adding Eggs |
||||
|
||||
When we run `egg2nix`, we obtain one collection of eggs with |
||||
mutually-compatible versions. This means that when we add new eggs, we may |
||||
need to update existing eggs. To keep those separate, follow the procedure for |
||||
updating eggs before including more eggs. |
||||
|
||||
To include more eggs, edit `pkgs/development/compilers/chicken/5/eggs.scm`. |
||||
The first section of this file lists eggs which are required by `egg2nix` |
||||
itself; all other eggs go into the second section. After editing, follow the |
||||
procedure for updating eggs. |
||||
@ -0,0 +1,34 @@ |
||||
# CUDA {#cuda} |
||||
|
||||
CUDA-only packages are stored in the `cudaPackages` packages set. This set |
||||
includes the `cudatoolkit`, portions of the toolkit in separate derivations, |
||||
`cudnn`, `cutensor` and `nccl`. |
||||
|
||||
A package set is available for each CUDA version, so for example |
||||
`cudaPackages_11_6`. Within each set is a matching version of the above listed |
||||
packages. Additionally, other versions of the packages that are packaged and |
||||
compatible are available as well. For example, there can be a |
||||
`cudaPackages.cudnn_8_3_2` package. |
||||
|
||||
To use one or more CUDA packages in an expression, give the expression a `cudaPackages` parameter, and in case CUDA is optional |
||||
```nix |
||||
cudaSupport ? false |
||||
cudaPackages ? {} |
||||
``` |
||||
|
||||
When using `callPackage`, you can choose to pass in a different variant, e.g. |
||||
when a different version of the toolkit suffices |
||||
```nix |
||||
mypkg = callPackage { cudaPackages = cudaPackages_11_5; } |
||||
``` |
||||
|
||||
If another version of say `cudnn` or `cutensor` is needed, you can override the |
||||
package set to make it the default. This guarantees you get a consistent package |
||||
set. |
||||
```nix |
||||
mypkg = let |
||||
cudaPackages = cudaPackages_11_5.overrideScope' (final: prev { |
||||
cudnn = prev.cudnn_8_3_2; |
||||
}}); |
||||
in callPackage { inherit cudaPackages; }; |
||||
``` |
||||
@ -0,0 +1,31 @@ |
||||
# Hy {#sec-language-hy} |
||||
|
||||
## Installation {#ssec-hy-installation} |
||||
|
||||
### Installation without packages {#installation-without-packages} |
||||
|
||||
You can install `hy` via nix-env or by adding it to `configuration.nix` by reffering to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it succesfully works with `python3`. |
||||
|
||||
::: {.caution} |
||||
Packages that are installed with your python derivation, are not accesible by `hy` this way. |
||||
::: |
||||
|
||||
### Installation with packages {#installation-with-packages} |
||||
|
||||
Creating `hy` derivation with custom `python` packages is really simple and similar to the way that python does it. Attribute `hy` provides function `withPackages` that creates custom `hy` derivation with specified packages. |
||||
|
||||
For example if you want to create shell with `matplotlib` and `numpy`, you can do it like so: |
||||
|
||||
```ShellSession |
||||
$ nix-shell -p "hy.withPackages (ps: with ps; [ numpy matplotlib ])" |
||||
``` |
||||
|
||||
Or if you want to extend your `configuration.nix`: |
||||
```nix |
||||
{ # ... |
||||
|
||||
environment.systemPackages = with pkgs; [ |
||||
(hy.withPackages (py-packages: with py-packages; [ numpy matplotlib ])) |
||||
]; |
||||
} |
||||
``` |
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue