"Helm releases" is what I'd been terming individual services, but
it makes no sense outside of the internal context of the Helm builder.
I also didn't want to call them "apps", however shorter that term is.
These are not apps.
I've changed release modules' signatures from:
`{lib} -> ... -> <drv>`
to:
`{lib} -> ... -> {out=<drv>; extra=<drv>;}`
Which makes individual derivations more easily findable.
Now, instead of picking them out from a soup of paths in `output.sh`
with a specially-crafted needle (`${ns}-${name}`), I map derivations
directly to paths and use the result as a sort of index. In other words,
I spent some ingenuity in `flake-builders.sh` to save a _lot_ of
ingenuity in `output.sh`.
This affords me the extra convenience, previously spurned because of
the very limitation I've overcome, of symlinking derivations in the
output flake.
I have my answer to 2638113, and it's what I was suspecting: the
flake-builder was never using clusterData until I added a release
that needs it, at which point I got the dreaded "error: attribute
'apiVersions' missing".
Remediation was simple: realize the wrongheadedness of passing
an empty attrset when the values are already well-known.
Line 62 of this commit's flake.nix should bail with an attribute-missing
error while evaluating `buildDerivations.releases`, at the point where
Nix tries to inherit two variables from an empty `clusterData`.
...Or is it that I will have problems when I add something using
lib.builders.helmChart to `./system`? I'll only find out tomorrow.
- Clarify nature of release paths.
- Explain why I haven't bothered to wedge values.yaml files into the
default derivation.
- Move drv_matcher to copy_drv_output, where it conceptually belongs.
kubelib.buildHelmChart can take the target Kubernetes version and
a list of custom APIs, so I'll bind them both up in an attrset
and pass them to `flake-builder.releases`.
Accordingly, the other release-builders will have to become variadic.
Also, I had a brief temptation to move `gatherApis` to `flake-builders`,
but apart from being used in the flake's let-in, it has little in common
with the other builders. I need to lose a direct dependency on kubelib
to try the concept out, though (`flake-builders` doesn't take `kubelib`),
and I ended up keeping the result.
My long-term vision for this flake is to use it as a control flake:
plug it into your homelab ("data-plane") flake and avail yourself
of its `lib.builders`, et cetera.
In short, I want this flake to be useful to many people, and that
means not shipping my homelab with it.
"Flake builder for charts could also take {fetcher, args}."
Except it shouldn't, because then I'll be peppering 98% of the modules
in `charts/` with `fetcher = lib.fetchers.helmChart`. Better to spend
a constant 100..150 chars on an extra flake-builder (fetchCharts) than
n*(30..50) chars on a refactor.
- Moved external ServiceEntry generator to `lib.resources`.
- Gave it some company: a generator of HTTPRoutes for gateway/svc.
- Gave `lib.vars.svcGateway` a parentRef generator, at the cost of
another level of recursion, and some variable renaming.
Everything I need directly from nix-kube-generators is now
handled in `lib/`. Additionally, now that I know buildYAMLStream always
takes a namespace and name, there's no need for the longer-winded name.
The reason I struggled with genericBuilders, and again when I replaced
`remoteYAML`'s NS-name `pname` with `url`, is that I was confusing the
following two things:
1. Things that fetch a resource (a Helm chart, a YAML stream, etc.)
without naming or namespacing it.
2. Things that create a release _by_ giving it a name and namespace
so that lib/output.sh can sort the resultant files into directories.
Additionally, I was questioning the good sense of releases/svc/gateway:
a release with no release, but only extra objects? Turns out I
needlessly bound the concept of JIT namespace injection to that
`extraObjects` feature. Once I abstracted that builder, the more general
solution became clear.
By declaring builders at the module level, only to call them in
flake.nix, I give myself the opportunity to inject `{name, namespace}`
there and need no longer pass these args into every module myself.
