WIP: 1st pass update for Manifest Generation guide

[kingdonb]

This update has at least one dependency, we need to author and merge the OCI Flux Getting Started Guide (it is linked here as https://FIXME)

I'll continue working on the text of this guide, we should be able to remove many of these examples as they are way too complicated and it's much easier now with OCI.

I have updated one of the later examples, the commentary needs another round of proof-reading and the earlier examples and subsequent later examples all need to get a similar treatment as well.

[kingdonb]

The aim is to get this guide down to about half the size. It will require removing some use cases.

I'm going to have to break some anchor hard-links in order to do this, but I think the end result will be positive.

If anyone feels strongly about the docs that are removed, we can host them again somewhere else. I have a personal blog where I can post them for example. I think the jsonnet/kubecfg stuff should be moved to a blog post on the fluxcd blog. I will keep that example for now, because it's about manifest generation and GitHub Actions, and this example actually provides an (understated) example of how to install any old manifest generator from GitHub releases, such as kubecfg.

I will try to make that part more prominent, and remove all of the other parts that are focused on different back and forth GitHub permissions between repos. We are not going to recommend users to write GitHub actions workflows that do commit back to the Git repository anymore. We can maybe keep one of these examples around, but there should not be so many, and we did not really explain the whole GitHub permissions system so it will not be a great loss if we remove some coverage of the weird permissions that are possible on GitHub IMHO. Those are things that do not really belong in the Flux docs.

I'm not sure where else they would go that they could fit in well, but let's see how this doc looks when it's about half as big.

[kingdonb]

I think this plan is still good,

We can recommend getghrel if it can be vetted as a way to fetch any manifest generator, rather than recommending some arbitrary github action for each manifest generator that people want to use. It would be good to build a GHA workflow for it.

https://www.reddit.com/r/commandline/comments/156bzks/introducing_getghrel_the_effortless_way_to_fetch/

The priority is to describe a workflow for Flux OCI that makes it clear which part is fixed in place, and which part is up to the user. For example, in your bootstrap repo, you might have an "apps" directory and it's full of subdirectories. And you want all apps installed on the bootstrapped cluster, but you don't want to write a flux-kustomization.yaml for each one – but we want them to reconcile independently, so a broken config for one app does not affect the others.

This should be easy to generate from CI with a list of the directories in apps and a little scripting around flux create kustomization --export > oci-temp/generated/...

Users might want to generate any myriad of things, one example with Cue and one example like as described above, without Cue would probably be illustrative of the power that you get when users adopt Flux OCI.

[kingdonb]

This still needs to happen (bump)