forked from clan/clan-core
The container test driver was creating an `.env` file containing all environment variables from the Nix build environment. This file was never read or used anywhere, but caused failures in services that automatically load .env files (like dbmate used by ncps). The `.env` file contained invalid `dotenv` syntax because Nix build variables include paths like `/nix/store/...`: ``` Error: loading env file(s) [.env]: unexpected character "/" in variable name near "/nix/store/zxdrfl80svri9zk1j64l77rksvrfqq87-nixos-test-driver-ncps/bin/nixos-test-driver -o $out\n\nNIX_CFLAGS_COMPILE= -frandom-seed=hq0v7gqlh0 ... ```
ClanLib
This folder is supposed to contain clan specific nix functions.
Such as:
- clan function
- select
- inventory function
- json-schema-converter
Structure
Similar to nixpkgs/lib this produces a recursive attribute set in a fixed-point.
Functions within lib can depend on each other to create new abstractions.
Conventions
Note: This is not consistently enforced yet. If you start a new feature, or refactoring/touching existing ones, please help us to move towards the below illustrated.
A single feature-set/module may be organized like this:
# ↓ The final clanLib
{lib, clanLib, ...}:
# ↓ portion to add to clanLib
{
inventory.resolveTags = tags: inventory.machines; # implementation
inventory.buildMachines = x: clanLib.inventory.resolveTags x; # implementation
}
Every bigger feature should live in a subfolder with the feature name. It should contain two files:
default.nixtest.nix- Everything else may be adopted as needed.
Example filetree
.
├── default.nix
├── clan
│ ├── default.nix
│ └── test.nix
└── inventory
├── services-subfeature
│ ├── default.nix
│ └── test.nix
├── instances-subfeature # <- We immediately see that this feature is not tested on itself.
│ └── default.nix
├── default.nix
└── test.nix
Testing
For testing we use nix-unit