ArgoCD using OCI as a source, what does it mean for GitOps promotions?

[BenHesketh21]

As one of the pushers for artefact branches and specifically focusing on promoting GitOps applications I felt like Kargo was the right place to ask this.

Kargo (and others) have been pushing in the direction of artefact branches for promotions and I wonder how that fits into the latest developments of GitOps using OCI artefacts as sources.

I feel like the simple answer is you have tags of an OCI repo for each environment and you're GitOps promotion tool could push your final manifests to that tag but then you lose things like a pull request workflow.

So I'm interested in Kargo contributors' views on this and how they see the future of GitOps promotions.

[krancour]

Subscribing to manifests (or other stuff, too, I suppose) stored in OCI repos is coming at some point. Pushing manifests (or other stuff) to OCI repos is probably coming sooner than that. There's no specific timeframe yet.

There are, I think, a few issues about this in some form and as recently as earlier today I've attempted to de-dupe. #1099 is the one I'm closing others in favor of.

In a nutshell, OCI doesn't change things much. It enables GitOps without Git.

Pushing artifacts to OCI and tagging them in some meaningful way is not much different from pushing them to Git. Subscribing to those isn't much different from our existing image and Helm chart subscription features.

Since you ask about rendered branches, specifically, you can certainly push/pull rendered manifests to environment-specific OCI repositories or push/pull rendered manifests for all environments to a single repository and use environment-specific tags. It's really up to you how you want things to work... and that's the caveat too...

You'll end up having to devise your own conventions to accomplish things Git gave you for free. The commits in a branch are ordered chronologically. You don't need to do anything at all to know which commit in a given branch is newest. It's obvious. With OCI, you'd have to establish and adhere to a semantically meaningful tagging convention to get the equivalent.

[BenHesketh21]

It is interesting because purely from a GitOps deployment point of view it seems like an obvious progression but from the point of view of promotions I think it makes things more difficult and less visible, like diffs for example. To get the diff before and after a promotion is easy with Git and you can do pull requests to get a preview before you actually promote but like you say, with OCI that will all have to be custom, or maybe even a new tool that handles that for you will emerge or even Kargo could create steps that help with it in the future?

[krancour]

You're asking the right things. I don't want to poo poo it, but my personal opinion is it's been overhyped.

Were I to use it myself, I probably wouldn't actually fully replace Git with it. I would probably opt for doing things as I currently do and maybe push to an OCI repo at the very tail end of a process. This way I could have the best of both worlds -- PRs that a person can actually review in Git, but after they're merged and a promotion process resumes, push the resulting manifests to an OCI repo, which, if you regard manifests as artifacts, seems like a nicer, more appropriate place for them.

I think it's important to remember there's already not one right way to do things. Kargo is unopinionated because many users have existing processes they're migrating from, some have very strongly held opinions about how things ought to be done, or sometimes approaches are constrained by technical factors or organizational policies. In the end, I think the notion of manifests in OCI repos is no panacea. It's only a Lego brick.

Again, these are personal opinions.

[frekw]

@krancour I think my take is similar, but opposite. I don't want OCI to replace Git as the source of truth of what's running in what stage, but rather the YAML serving as input to the promotion itself, and then having the promotion render and commit the final YAML.

That would make it very smooth to have a workflow where all code (application code and Kubernetes config) lives next to one another in the same repository, where the CI builds to artifacts; the application image and a compiled version of the Kubernetes configuration (e.g using higher level tools like cdk8s), and pushes both as two OCI images. To me, this makes a lot of sense, because a lot of the Kubernetes configuration is tied to application code (e.g what configuration options are supported).

Kargo could then pick up both images, unpack the YAML, apply its promotion step and commit the final, fully rendered YAML, to another Git repository, describing the current state of each stage.