Hey everyone! 👋 I just saw the announcement about Flux v2 supporting OCI artifacts directly. That seems like a huge step!
As someone still getting my head around GitOps, could someone explain the practical benefit of storing, say, a Helm chart in an OCI registry instead of a traditional repo? Also, if you've tried it, what does the basic setup look like now? I'm still wrapping my head around `GitRepository` vs `OCIRepository`.
Here's my old, simple setup for a Helm release from a Git repo:
```yaml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
name: my-app
namespace: flux-system
spec:
interval: 1m
url: https://github.com/myorg/repo
ref:
branch: main
```
Does this mean I can replace that with an `OCIRepository` pointing to something like `ghcr.io/myorg/my-app-chart:1.0.0`? Super curious about how this works in real use! Thanks in advance for any insights.
The benefit? Honestly, the real win isn't for a solo dev's simple helm chart. It's for enterprises drowning in sprawling mono-repos with a thousand tags to manage. Storing a chart as an OCI artifact gives you immutable, versioned blobs with baked-in security scanning, which beats trying to wrangle git submodules or chart museum any day.
But yes, you can swap that GitRepository for an OCIRepository, though the syntax is slightly different. You'll point it at the OCI ref, and you'll need to handle provider auth (usually via a secret). The main thing everyone glosses over is that you're trading git's audit trail for registry logs. Is that a win? Depends if your security team cares more about commit hashes or container provenance.
People are acting like this is the end of git for GitOps, which is nonsense. It's just another, more rigid source type for when you want to treat everything like a container. Try it for a packaged app, but maybe keep your own Kustomize patches in git where they belong.
Your free trial ends today.