Expose OCI origin revision in events - #2127
Conversation
|
How does this affect kustomize-controller and helm-controller since they inject the originRevision on their own. Will it end up as a duplicate? |
The controllers emit independent events. source-controller will have its own messages, reasons, object kind, etc. I'd not call this a duplicate. The Alert API allows filtering which events you want to propagate to the Provider, so this LGTM. |
OCI artifacts can record their source revision in the org.opencontainers.image.revision annotation. Include that value in successful events so notification consumers can correlate an artifact with its source commit. Keep the existing artifact revision unchanged and omit the extra event metadata when the annotation is empty. Signed-off-by: Ruslan Shaydullin <shaydullin.r.d@outlook.com>
d540df7 to
dd0a04c
Compare
|
I’ve updated the branch to the current main, and the PR still shows as approved and mergeable. The e2e, test, and scan workflows are awaiting maintainer authorization—could you please authorize them? Please let me know if anything else is needed from my side. |
3 participants
OCI artifacts can record their source revision in the
org.opencontainers.image.revisionannotation. This forwards that value assource.toolkit.fluxcd.io/originRevisionon successful OCIRepository events,allowing notification consumers to correlate an artifact with its source
commit.
The existing artifact revision and event message remain unchanged. The extra
event metadata is omitted when the annotation is empty or absent.
Closes fluxcd/notification-controller#1284
Testing
go test ./internal/controller -run '^TestOCIRepositoryReconciler_notify$' -count=1go test -race ./internal/controller -run '^TestOCIRepositoryReconciler_notify$' -count=1go vet ./...cd api && go vet ./...git diff --check