mirrors/turboprop
1
0
Fork 0
mirror of https://git.sr.ht/~goorzhel/turboprop synced 2024-12-14 11:37:37 +00:00
Code Activity

In ADRs, document assumptions and fix typos

Browse source
This commit is contained in:
Antonio Gurgel 2023-12-03 18:00:15 -08:00
parent 797ae401ae
commit 1bde5552c5
2 changed files with 29 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
adr/1.md
View file

@ -7,7 +7,7 @@ As planned at `3b5168f`, I started using multiple service trees at commit
at `./services` for those that used Helm's `Capabilities.APIVersions` to
determine the presence of those CRDs.
## Considered Options
## Considered options
### Previous solution: per-variable trees
Because I struggled with infinite recursion early on, I did this in a very dumb
@ -31,7 +31,7 @@ But something struck me:
### New solution: ordered list of trees
Here's a thought. Instead of
Instead of
```nix
systemServiceData = rake.leaves ./system;
@ -51,7 +51,7 @@ services = flakeBuilders.services self.serviceData {
};
```
I do instead:
I will do:
```nix
stages = (ls ./services);
@ -80,3 +80,25 @@ Since I don't know for sure how common this use case is, I may as well herd ever
until someone complains.
More to come after I actually write `buildServices` in `src/default.nix`.
## Some other assumptions made
### `./services` is where _all_ service modules go
I don't expect there to be multiple service-tree roots, such as `./system`.
Especially not with Haumea, whose recursive operation allows there to be zero
or more directory layers between the root, the namespace directory, and the
service module. In my case, there is one layer: the ordering directory.
```
services/00-istio/istio-system/base
# root
# ordering (arbitrary directory layer)
# namespace (req'd by serviceLoader)
# name (req'd by serviceLoader)
```
### Each service module's parent dir is its namespace
This assumption has held fast since the beginning, and will continue to hold fast indefinitely.
It's just common sense.

5
adr/2.md
View file

@ -1,5 +1,7 @@
# ADR 2: Using directory trees as data
## Context
In `a2abba2` or sometime around then, I borrowed Nixhelm's [leaf-raking paradigm](https://github.com/farcaller/nixhelm/blob/e0383f7c11000f8c141a7d26197ee402424b017d/flake.nix#L9-L23) (and named it after [Digga's](https://github.com/divnix/digga/blob/baa54f8641ee9128cdda8b508553284c331fc9f1/src/importers.nix#L61-L114)...although this is the first time I'm looking directly at it, and now I'm realizing I could have just borrowed that very code.)
Example input and output, using `kubernetes@2de43d7`:
@ -53,7 +55,7 @@ Raking a service tree like this reduces the need to litter the source tree with
`default.nix` files (as seen in, e.g., [nixos-hardware](https://github.com/NixOS/nixos-hardware/tree/a89745edd5f657e2e5be5ed1bea86725ca78d92e)).
However, it imposes assumptions about the source tree that ADR 1 rendered invalid.
## Considered Options
## Considered options
### Adapt existing code
@ -82,6 +84,7 @@ nix-repl> serviceData."0-istio".istio-system."1-18-1"
This leads to another conundrum: how now will I rake the data and pass it to the flake builders?
Solution: don't bother raking the data in advance; use a flake-builder with a custom loader.
## Decision