When using a generic provider with an Alert that watches OCIRepository and Kustomization resources, the webhook payload does not include a structured commit field or human-readable revision reference. The metadata.revision field contains an OCI digest (e.g. latest@sha256:8af90b59...) which is not useful for correlating a reconcile event back to a meaningful release identifier.
To Reproduce
Create a Provider of type: generic pointing to a webhook endpoint:
apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
name: control-plane-webhook
namespace: flux-system
spec:
type: generic
address: http://my-backend/api/flux-events
Create an Alert watching OCIRepository and Kustomization event sources:
apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
name: product-status-tracker
namespace: flux-system
spec:
eventSeverity: info
eventSources:
- kind: Kustomization
name: '*'
namespace: flux-system
- kind: OCIRepository
name: '*'
namespace: flux-system
providerRef:
name: control-plane-webhook
Trigger a reconcile by pushing a new OCI artifact.
Inspect the payload received by the webhook endpoint.
Observed behavior
The payload metadata does not contain a commit key. The metadata.revision value is an OCI digest string:
{
"involvedObject": { "kind": "Kustomization", "name": "my-app-root", ... },
"severity": "info",
"message": "Applied revision: latest@sha256:8af90b59f8ae328d...",
"metadata": {
"revision": "latest@sha256:8af90b59f8ae328d...",
"summary": "..."
}
}
There is no commit field in metadata, unlike what the github provider type surfaces.
Expected behavior
Either:
metadata.commit is populated with the OCI digest (or a short form of it) so consumers of the generic webhook can extract a meaningful identifier, or
The documentation explicitly states that structured commit metadata is only available for SCM-backed provider types (github, gitlab, gitea, etc.) and explains what generic consumers should use instead.
Environment
Flux version: v2.8.3
notification-controller version: v1.8.2
Source type: OCIRepository (OCI artifact, not Git-backed)
Provider type: generic
Additional context
The core need is to correlate a reconcile event to a specific artifact push. For Git-backed sources, metadata.commit is well-defined. For OCI-backed sources via generic, there is no equivalent enriched field — the digest is only embedded inside the human-readable message string, making programmatic extraction brittle.
When using a generic provider with an Alert that watches OCIRepository and Kustomization resources, the webhook payload does not include a structured commit field or human-readable revision reference. The metadata.revision field contains an OCI digest (e.g. latest@sha256:8af90b59...) which is not useful for correlating a reconcile event back to a meaningful release identifier.
To Reproduce
Create a Provider of type: generic pointing to a webhook endpoint:
Create an Alert watching OCIRepository and Kustomization event sources:
Trigger a reconcile by pushing a new OCI artifact.
Inspect the payload received by the webhook endpoint.
Observed behavior
The payload metadata does not contain a commit key. The metadata.revision value is an OCI digest string:
There is no commit field in metadata, unlike what the github provider type surfaces.
Expected behavior
Either:
metadata.commit is populated with the OCI digest (or a short form of it) so consumers of the generic webhook can extract a meaningful identifier, or
The documentation explicitly states that structured commit metadata is only available for SCM-backed provider types (github, gitlab, gitea, etc.) and explains what generic consumers should use instead.
Environment
Flux version: v2.8.3
notification-controller version: v1.8.2
Source type: OCIRepository (OCI artifact, not Git-backed)
Provider type: generic
Additional context
The core need is to correlate a reconcile event to a specific artifact push. For Git-backed sources, metadata.commit is well-defined. For OCI-backed sources via generic, there is no equivalent enriched field — the digest is only embedded inside the human-readable message string, making programmatic extraction brittle.