This has overlap with #514, and is in general quite the change to accept without more discussion among maintainers.

I suggest you join one of our project meetings to further discuss your proposal.

Nice, thanks for pointing that out! I didn't know about the meetings, I joined the list and subscribed to the calendar here!! Thanks 🙏 🙏 🙏

Closing this in favour of fluxcd/notification-controller#519

Can we re-open this one? Yes, there is an overlap with #514, but this one here tackles a different issue.

My use-case:
I have an app which creates deployments via the GitHub API. Then in the same step, it writes a HelmRelease manifest to a repository which is reconciled via FluxCD. After the reconciliation, I want to use the notification-controller to call my app again, which then calls the deployments API again to show the deployment as done.

To be able to match the created HelmRelease with the deployment though, I would want to add some identifying data to the HelmRelease manifest and then return this as metadata via the notification-controller.

@matheuscscp Any chance you joined a meeting and brought this up already?

@matheuscscp And more on-topic, would it be enough to just include the manifest's .metadata.labels and/or .metadata.annotations?

@matheuscscp Any chance you joined a meeting and brought this up already?

I can do it this week 👌

Hey @moritzschmitz-oviva, while this feature is not available in the HelmRelease API, would you let me know if the equivalent on the Alert API suffices for your use case? See this: https://fluxcd.io/flux/components/notification/alerts/#event-metadata

Hey @moritzschmitz-oviva, while this feature is not available in the HelmRelease API, would you let me know if the equivalent on the Alert API suffices for your use case? See this: https://fluxcd.io/flux/components/notification/alerts/#event-metadata

Hm, just had another look and it would suffice if I change my setup a bit.

My folder structure right now:

• alert.yaml
• namespace/application/release.yaml

I could change to:

• namespace/application/alert.yaml
• namespace/application/release.yaml

What I am trying to say: I could add an Alert on a per-deployment basis and then add the deployment-specific metadata to the Alert directly. Not my ideal way, because I multiply resources, but works as workaround.

@moritzschmitz-oviva One question: how would you identify the GitHub deployment?

@moritzschmitz-oviva One question: how would you identify the GitHub deployment?

The API returns an ID when creating a deployment: https://docs.github.com/en/rest/deployments/deployments?apiVersion=2022-11-28#create-a-deployment.

We have a GitHub app which creates a deployment via above API and then modifies files inside the FluxCD repository. When we create the files, we already have the ID and can set it as a metadata field. Now when the notification-controller reports the successful installation of the HelmRelease we call the GitHub app again and pass the metadata. It then knows which deployment to 'proceed'. Does that make sense?

Hey @moritzschmitz-oviva I just wanted to let you know that we are going to support sending object annotation keys prefixed with a to-be-defined API Group, e.g. something like events.toolkit.fluxcd.io/myCustomMetadataKey or notification.toolkit.fluxcd.io/myCustomMetadataKey. This will be supported across all Flux controllers in a uniform way, not just for HelmRelease. I will open an RFC in the flux2 repo for this.

@matheuscscp This is seriously great news! Thanks for picking this up! 🚀

@moritzschmitz-oviva Feel free to comment: https://github.com/fluxcd/flux2/pull/4809/files