60768cc537
This adds a (for now hidden) clan network command that exposes list, ping, overview subcommands to get informations about configured networks. ClanServices can now use the exports to define network specific information. This is not the complete feature yet, as we are lacking more tests and documentation, but merging this now makes it easier to iterate.
ClanLib
This folder is supposed to contain clan specific nix functions.
Such as:
- build-clan function
- select
- build-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:
impl.nixtest.nix- Everything else may be adopted as needed.
Example filetree
.
├── default.nix
├── build-clan
│ ├── default.nix
│ └── test.nix
└── inventory
├── default.nix
├── services-subfeature
│ ├── default.nix
│ └── test.nix
├── instances-subfeature # <- We immediately see that this feature is not tested on itself.
│ └── default.nix
└── test.nix
# default.nix
{lib, clanLib, ...}:
{
inventory.resolveTags = import ./resolveTags { inherit lib clanLib; };
}
Testing
For testing we use nix-unit
TODO: define a helper that automatically hooks up tests in flake.legacyPackages and a corresponding buildable checks attribute