meta(rules): Add project-specific rules and skills
Some checks failed
Build / build (Development) (push) Blocked by required conditions
Build / build (Testing) (push) Blocked by required conditions
Build / Determining hosts to build (push) Failing after 10m11s

This commit is contained in:
Tibo De Peuter 2026-03-17 18:40:05 +01:00
parent 5a031b48ed
commit 65976c76c7
Signed by: tdpeuter
GPG key ID: 38297DE43F75FFE2
2 changed files with 90 additions and 0 deletions

View file

@ -0,0 +1,39 @@
# Bos55 NixOS Configuration Style Guide
Follow these rules when modifying or extending the Bos55 NixOS configuration.
## 1. Network & IP Management
- **Local Ownership**: Define host IP addresses only within their respective host configuration files (e.g., `hosts/BinaryCache/default.nix`).
- **Dynamic Discovery**: Do NOT use global IP mapping modules. Instead, use inter-host evaluation to resolve IPs and ports at build time:
```nix
# In another host's config
let
bcConfig = inputs.self.nixosConfigurations.BinaryCache.config;
bcIp = (pkgs.lib.head bcConfig.networking.interfaces.ens18.ipv4.addresses).address;
in "http://${bcIp}:8080"
```
## 2. Modular Service Design
- **Encapsulation**: Services must be self-contained. Options like `openFirewall`, `port`, and `enableRemoteBuilder` should live in the service module (`modules/services/<service>/default.nix`).
- **Firewall Responsibility**: The service module is responsible for opening firewall ports (e.g., TCP 8080, SSH 22) based on its own options. Do not open ports manually in host files if the service provides an option.
- **Remote Builders**: If a service like Attic supports remote building, include the `builder` user, trusted-users, and SSH configuration within that module's options.
## 3. Container Networking
- **Discovery by Name**: Host services should connect to their companion containers (e.g., PostgreSQL) using the container name rather than `localhost` or bridge IPs.
- **Host Resolution**: Use `networking.extraHosts` in the service module to map the container name to `127.0.0.1` on the host for seamless traffic routing.
## 4. Secrets Management (sops-nix)
- **Centralized Config**: Fleet-wide `sops-nix` settings (like `defaultSopsFile` and `age.keyFile`) must live in `modules/common/default.nix`.
- **No Hardcoded Paths**: Always use `config.sops.secrets."path/to/secret".path` to reference credentials.
## 5. DNS & DNS Zone Files
- **Serial Increment**: Every change to a Bind9 zone file (e.g., `db.depeuter.dev`) MUST increment the `Serial` number in the SOA record.
- **Specific Domains**: Prefer a single, well-defined domain (e.g., `nix-cache.depeuter.dev`) over multiple aliases or magic values.
## 6. CI/CD Robustness
- **IP-Based Login**: When CI runners (Gitea Actions) need to interact with internal services, use direct IP addresses (e.g., `192.168.0.25`) for login/auth to bypass potential DNS resolution issues in the runner environment.
## 8. Git Workflow & Commits
- **Atomic Commits**: Each commit should represent a single logical change and be easily revertible. Split docs, metadata, and core code changes into separate commits.
- **Conventional Commits**: Use conventional commit messages (e.g., `feat:`, `fix:`, `docs:`, `refactor:`, `ci:`, `meta:`).
- **Branching**: Always work in feature branches and push to origin to create pull requests.

View file

@ -0,0 +1,51 @@
---
name: bos55-nix-config
description: Best practices and codestyle for the Bos55 NixOS configuration project.
---
# Bos55 NixOS Configuration Skill
This skill provides the core principles and implementation patterns for the Bos55 NixOS project. Use this skill when adding new hosts, services, or networking rules.
## Core Principles
### 1. Minimal Hardcoding
- **Host IPs**: Always define IPv4/IPv6 addresses within the host configuration (`hosts/`).
- **Options**: Prefer `lib.mkOption` over hardcoded strings for ports, domain names, and database credentials.
- **Unified Variables**: If a value is shared (e.g., between a PG container and a host service), define a local variable (e.g., `let databaseName = "attic"; in ...`) to ensure consistency.
### 2. Service-Driven Configuration
- **Encapsulation**: Service modules should manage their own firewall rules, users/groups, and SSH settings.
- **Trusted Access**: Use the service module to define `nix.settings.trusted-users` for things like remote builders.
### 3. Build-Time Discovery
- **Inter-Host Evaluation**: To avoid magic values, resolve a host's IP or port by evaluating its configuration in the flake's output:
```nix
bcConfig = inputs.self.nixosConfigurations.BinaryCache.config;
```
- **Domain Deferral**: Client modules should defer their default domain settings from the server module's domain option.
## Implementation Patterns
### Container-Host Connectivity
- **Pattern**: `Service` on host -> `Container` via bridge mapping.
- **Rule**: Map the container name to `127.0.0.1` using `networking.extraHosts` to allow the host service to resolve the container by name without needing the bridge IP.
### Secrets Management
- **Rule**: Standardize all secrets via `sops-nix`.
- **Common Module**: Ensure `modules/common/default.nix` handles the default `sopsFile` and `age` key configuration.
### Bind9 Management
- **Rule**: **ALWAYS** increment the serial when editing zone records.
### CI/CD Networking
- **Rule**: Use direct IPs for machine-to-machine login steps in Actions workflows to ensure reliability across different runner environments.
## 4. Security & Documentation
- **Supply Chain Protection**: Always verify and lock Nix flake inputs. Use fixed-output derivations for external resource downloads.
- **Assumptions Documentation**: Clearly document environment assumptions (e.g., Proxmox virtualization, Tailscale networking, and specific IP ranges) in host or service READMEs.
- **Project Structure**: Maintain the separation of `hosts`, `modules`, `users`, and `secrets` to ensure clear ownership and security boundaries.
### 5. Git Standards
- **Rule**: Follow **Conventional Commits** (e.g., `feat:`, `refactor:`, `docs:`, `meta:`).
- **Rule**: Keep commits **atomic** and **revertible**. Never mix documentation, infrastructure, and style guide changes in a single commit.