Codified updates to git

[ellieayla]

Many people are looking for GitOps to replace some imperative existing model, like a CI job running kubectl set image .... This often results in people independently authoring janky shell scripts that end up needing to...

0. decide something about the world, like some new image being ready for use in production
1. enough resource type awareness to edit some files - Possibly flimsy, such as with sed / envsubst
2. make a commit
3. push it somewhere and
   • make a PR (vendor-specific api) for something else to review or automerge
   • deal with merge conflicts - possibly rebase or discard & retry

FluxCD v1 implemented a stack of code for detecting & bumping image versions, but never dealt with the generalized case directed by some other tooling. Other bits in the GitOps toolkit may. An opinionated way to implement a common flow should be documented. And ideally not require the end-administrator to reimplement common logic themselves.

[todaywasawesome]

We'll want to be careful document the best practice and not necessarily pick a winning tool with it.

[scottrigby]

Agree with @todaywasawesome. The scope of this WG is concerned with patterns, definitions, criteria, and practices. Tools should work to implement these, not the other way around.

@alanjcastonguay that said, this is a commonly requested process for GitOps, and I'd love to see tool-agnostic use cases and patterns for this more fleshed out in a working doc.

[scottrigby]

@ellieayla Revisting this – now that we're farther along with OpenGitOps, this could be a good "blueprint" for OpenGitOps

Also perhaps could make a good Flux doc or blog post – if you're interested in that side of things too, please ping me or others in the CNCF #flux-contributors channel 😄 ✨