use-case: GitHub Actions Manifest Generation #1200
Conversation
kingdonb
force-pushed
the
jsonnet
branch
2 times, most recently
from
ecd727f
to
a044732
Compare
kingdonb
force-pushed
the
jsonnet
branch
4 times, most recently
from
e97f20e
to
e4c801e
Compare
|
I think 100% of the content is all here now. There are four main Jsonnet examples with some sub-examples. It is pretty heavy, as I had to "X in Y" rapid-fire learn Jsonnet in Y hours, and I wanted to capture as much of that as possible to make this more accessible to audiences like me, who haven't necessarily worked with Jsonnet before. The examples are progressive. There is again more commentary, but it is focused more heavily around the later Jsonnet examples, and less about the history of Flux and the "v1 automation compatibility shim," which is glossed over and presented with as little glorification as I can muster. The shim, for tl;dr, is supposed to enable CI systems to set the image to the latest for clusters that have to behave exactly like Flux v1 automation for some reason. It was explained briefly at last week's Flux meeting, but I'll repeat this idea now for anyone who wasn't present there: The goal is not to convince people to use this shim forever or emulate Flux v1, it is presented as a stop-gap that you can use if you are fighting with waterfall delivery, or long-term planning and resource allocation that prohibits doing the migration in the order prescribed by Flux's migration guides. Assuming that all Flux v1 installations are to be decommissioned by a certain date, it is reasonable to anticipate that some organizations running parallel Flux v1 and v2 implementations will insist that Flux v2 be configured to behave as much like Flux v1 as possible until the cut-off arrives. It's been explained (and it is explained in the text of this guide) that this strictly isn't possible without providing more outside support, because of the deprecation of I will be running through the examples this evening with a fresh workstation, another original application, and a brand new flux-system repo on empty cluster, just looking to repeat all the steps and to catch omissions, and trying to replicate the full list of examples without context, as any reader coming in to this example would be expected to do while following the text. I'm not expecting to find major issues as I've been working these examples as I write them, they all should work. At this point I'm looking for feedback in the form of people who are interested in Jsonnet or GitHub Actions that are willing to test, and read through the examples similarly looking for mistakes or missing references, or I don't know, for example any flying leaps, like "how did you get here", or anything else which is maybe not clear enough for an average Flux user to follow. Hopefully we can agree on any changes requested and then merge this in by the end of the week? |
|
I stopped to reformat all of the links to use the footer-driven link format, so they can be more readable in the plaintext markdown formatted version of the text. Almost finished with that change. |
kingdonb
force-pushed
the
jsonnet
branch
3 times, most recently
from
875d620
to
12a3719
Compare
|
The markdown itself is much more readable now. Hopefully this will make it easier to follow the examples, and especially easier to read and approve for content-editing and other reviewing purposes. |
|
|
||
| The alternative is racy and doesn't always guarantee the latest commit will be the one that is deployed, since this behavior depends on the time that each commit is pushed, and even precisely how long the build takes to complete; the difference is fine for Dev environments, but this is not a strategy for Production use cases. | ||
|
|
||
| Your app's CI can commit and push YAML manifests (or one manifest for each app) into a separate deploy branch for `Kustomization` to apply. The deploy branch in a separate repository should be a branch to which the CI user is granted write access. |
There was a problem hiding this comment.
I need to test this with a more than trivial setup. Who is the CI user in GitHub Workflow?
Across repositories, it is whichever user's Personal Access Token was used. Within a single repo, is it whoever pushed the commit that triggered the workflow? Are there any pitfalls of this, can you still protect the deploy branch and allow writes to it – through the workflow only? (Maybe you need to use a PAT to achieve this, even within the same repo?)
Probably a question that is out of scope for this example use case document, but some folks might trip over this.
stefanprodan
changed the title
It is probably not elegant or idiomatic jsonnet. I am learning Jsonnet. I believe the explanation is correct, but I still have to retry this example for repeatability and check for completeness. * Jsonnet example - gutted * take some personalize things away * clean up awkward sentence * for real gitops Signed-off-by: Kingdon Barrett <kingdon@weave.works>
Signed-off-by: Kingdon Barrett <kingdon@weave.works>
Signed-off-by: Kingdon Barrett <kingdon@weave.works>
Signed-off-by: Kingdon Barrett <kingdon@weave.works>
Signed-off-by: Kingdon Barrett <kingdon@weave.works>
Signed-off-by: Kingdon Barrett <kingdon@weave.works>
This part of the jsonnet example was missing a reference and needed a bit more explanation to accompany the missing reference. Signed-off-by: Kingdon Barrett <kingdon@weave.works>
Closes #1083
Resolves fluxcd/flux#3433
For your review!
I think the level of commentary is about right now. There may still be some rough sections remaining toward the end of the doc. Reviews are appreciated.