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 try to insert line breaks where a thought fragment ends (a habit
learnt from writing subtitles), but in comments and Git commit
messages it doesn't make as much sense.
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.
Packages can either output new APIs or expect them in the cluster.
Examples of packages which
- output APIs: Gateway API, which installs various versions of
gateway.networking.k8s.io resources.
- take APIs as input: app-template, which queries the cluster to
choose v1a2, v1b1, or v1 for its HTTPRoute (etc.) objects.
("Packages" here collectively refers to Helm charts and YAML bundles.)
I will have to impose strict ordering on them, i.e., build the former
before the latter.
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.
