Gonne/nixConfig
1
0
Fork 0
forked from Fachschaft/nixConfig
Code Pull requests Activity

added some first contributing guidelines and changed the config skeleton

Browse source
This commit is contained in:
Dennis Frieberg 2023-11-08 00:47:45 +01:00
parent 238faa3e89
commit 715c10c418
Signed by untrusted user: nerf
GPG key ID: 42DED0E2D8F04FB6
1 changed files with 33 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
README.md
View file

@ -146,8 +146,7 @@ machine. The only technically required file in there is `configuration.nix`. So
A good skeleton is probably:
```
flake-inputs:
{config, pkgs, lib, ... }: {
{config, pkgs, lib, flake-inputs, ... }: {
imports = [
./hardware-configuration.nix
@ -170,6 +169,10 @@ In your hardware
configuration you should basically only write you filesystem layout and your hostPlatform. The bootloading stuff
is already taken care of by `../../roles`.
The `flake-inputs` argument is optional, but you can use it if you need to get a hold of the flake inputs,
else this is a complete normal nixos system configuration module (with a lot of settings already imorted
from `../../roles`).
As of moment of writing `network.nix` should contain ip, nameserver and default gateway setup. As parts of
this is constant across all systems and will undergo refactor soon.
@ -278,3 +281,31 @@ something like this:
{lib, pkgs, config, ...} :
<module code >
```
# Contributing
Like with all FS projects, you are welcome to contribute. Work is done usually by the person that is most annoyed
by the circumstances or by the person that didn't run fast enough. So we are happy if we get help. That doesn't
mean that we don't need to have some level of quality, people after us needs to work with it. It is live infrastructure
and downtime hurts someone (and in the wrong moment even really bad (Matheball ticket sales for example)).
So here are some Guidelines.
## Coding style and linting.
If you run `nix flake check` there are automated checks in place, please make sure to pass them.
There is also a code autoformatter (`alejandra`) incorporated into those. If you want to run
it you can do so over the development shell or by running `nix fmt`.
You can also install
them into your local git repository as pre-commit hooks, and setting up a shell that has
even more tooling by running `nix develop`. That will give you a bash in which you can run
all the checks manually `pre-commit run -a`. This will also run the autoformatter.
## Process for submitting changes
1. If it is something bigger, please open an issue first describing what and why you want to do something.
If it is just something small, skip this step.
2. Fork the repo and implement your changes in a branch on your fork. Afterwards open a pull request (possibly mentioning the issue).
Against the main branch.
- Your branch should be based on an up to date version of main, if it is not consider rebasing.
3. You will need to find someone with the proper rights to approve of your changes, but most of the time there will be request
for changes first.