write OCIRepository origin revision to event metadata

[zevisert]

I have been experimenting with flux 2.4.0, and was surprised to find out that git commit status updates are not supported when using OCIRepository manifest sources, despite the examples in the docs https://fluxcd.io/flux/cmd/flux_push_artifact/#synopsis (permalink) suggesting to annotate the artifact with the source revision, for example, the first example shows using --revision:

flux push artifact oci://ghcr.io/org/config/app:$(git rev-parse --short HEAD) \
	--path="./path/to/local/manifests" \
	--source="$(git config --get remote.origin.url)" \
	--revision="$(git branch --show-current)@sha1:$(git rev-parse HEAD)"

What's the point of annotating these artifacts if the source revision is not used by the notification controller?

---

What I'd like to see is when reconciling a kustomization from an OCIRepository source, calls to KustomizationReconciler.event(...) that have the source available (some calls won't have a source, such as when access is denied) include the org.opencontainers.image.revision annotation that's included in the source manifest's annotations. One obvious example of where I'd like to see this is on the event successfully reconciled event:

kustomize-controller/internal/controller/kustomization_controller.go

Lines 198 to 201 in 29080cb

	r.event(obj, obj.Status.LastAppliedRevision, eventv1.EventSeverityInfo, msg,
	map[string]string{
	kustomizev1.GroupVersion.Group + "/" + eventv1.MetaCommitStatusKey: eventv1.MetaCommitStatusUpdateValue,
	})

[zevisert]

Since the kustomizev1.GroupVersion.Group + "/" + eventv1.MetaCommitStatusKey (ie kustomize.toolkit.fluxcd.io/revision) already contains the OCI tag and digest, it's probably best to add a new key to the event metadata, like the existing "org.opencontainers.image.revision" and "org.opencontainers.image.source" that are (read: should be) already present on the oci manifest's annotations

[stefanprodan]

What's the point of annotating these artifacts if the source revision is not used by the notification controller?

They are meant for flux trace command, so you can trace back an in-cluster resource to its Git origin.

[zevisert]

Ah okay, either way I think my request still stands? I took a look at the code, what do you think about passing KustomizationReconciler.event(...) a Context and letting it attempt to see if the source is OCI since it already has the Kustomization, then append the metadata from it to the event? I could make a PR for that, then look at updating the notification controller to try and consume a different annotation first, if it exists?

[zevisert]

I could also try to add the logic to lookup annotations on the OCI source directly to the notification controller, using the event's InvolvedObject to check if the associated source is OCI and if it has a revision annotation to parse. I'm betting that's the better option is to put the correct revision information in the event rather than having an event consumer do extra work to look up additional information.