I would like to extend this proposal. Sometimes using Application labels may not be enough, because important labels are on the AppProject only (our another case). So I propose to allow to expose particular labels from AppProject as well.

And it would be great to enable this for prometheus metrics as well.

I think this would be useful. However, I have a slight concern about using both, labels from Application and AppProject here.

If both, Application and AppProject have a label with the same name, but a different value, how would we decide which one will end up on the event? Making this configurable would considerably increase the effort to be put into the change for little value add. I'd prefer it to be a one-size-fits-all solution, i.e. to just copy all labels from the Application over to the Event, minus the ones that are already defined (dest-namespace and dest-server).

I have several ideas:

• specify both AppProject labels and AppProject labels (enabled for storing in events) as different application-controller arguments ("events-application-labels" and "events-appproject-labels" for example) and fail start when both arguments contain same label
  • and similarly for metrics - metrics-application-labels / metrics-appproject-labels
• prioritize Application before AppProject and have only one argument for both labels (more precisly one argument for both Application and AppProject for event and another one for both Application and AppProject for metrics), so when Application and AppProject both of them have values for the same label - Application wins
  • so first get labels from AppProject and then get labels from Application (with override)

I prefer second variant ("prioritize Application before AppProject") - almost the same as you said. But I'm not sure if you count with argument for selecting labels for propagating to events. I count with it, because propagating labels to metrics is based on it.

There is also possibility to have only one argument for all combination Application/AppProject, metrics/events (and not different for metrics and events as I stated above). It doesn't matter in our case.

As long as this behaviour is documented, I'd be fine with labels on the Application to override labels from the AppProject on the emitted events.

I was wondering though, what ends up on the events should be annotations, not labels, right?

We count with labels.
Also current implementation of metrics exposing counts with labels (see https://argo-cd.readthedocs.io/en/stable/operator-manual/metrics/#exposing-application-labels-as-prometheus-metrics).

I am working on implementing this feature and was thinking, would it make sense to have all the app & proj labels added by default without making it configurable. We already have lot of configurable params in Argo CD and making this configurable will introduce 2 more flags in app-controller and argocd-server.
Although, I believe adding all the labels in events may not have a significant impact on performance/storage/security, I am not sure on other potential consequences.

Hi @mrysavy , @jannfis, I have a PR (#18160) up to implement this enhancement. I have introduced a new key in argocd-cm instead of cli flags. Configmap approach made more sense to me as we could eliminate the need of updating flag configurations in 2 places i.e app-controller and argocd-server. PTAL. Thanks.

Hi @svghadi, I've tried the patch and it looks good. Thanks for the implementation