Proposal for Exposing Target Revision in Application Metrics Endpoint

[Lolelinus13]

Summary

Expose the target revision of the application in the metrics endpoint.

Motivation

I aim to display the target revision of several applications across different clusters on Grafana dashboards. At present, the argocd_app_info metric lacks a target_revision label.

Proposal

Proposed metric addition: argocd_app_info{target_revision="v2.11.3"}

[omerap12]

I can help with that if necessary :)

[Lolelinus13]

Yes sure, would be nice.

[andrii-korotkov-verkada]

Target revision may not match the revision that actually updated the manifests for a given app though and may be totally unrelated.

[omerap12]

hmmmm, I can grab the targetRevision from the sync status itself . what do you think? @andrii-korotkov-verkada

[andrii-korotkov-verkada]

I think the issue is not that it's hard to grab the revision, but that it probably isn't revision you want. For example, imagine several commits were pushed, only one of which updated your app and it wasn't the last commit. ArgoCD would use the last revision and that's what you'd see in the metrics, but the revision can be unrelated to your app. Can you tell more about your use case for the revision, please?

[omerap12]

oh I see. I haven't thought about it . But for our use case we use tags. so let's say we push a commit that changed app A - I tagged this commit and set the targetRevision to this tag. app B will have it's own tag.

[andrii-korotkov-verkada]

Do you use something like https://argo-cd.readthedocs.io/en/stable/user-guide/tracking_strategies/#tag-tracking? If so, the target revision may be relevant to the app, as my concerns probably only apply to https://argo-cd.readthedocs.io/en/stable/user-guide/tracking_strategies/#head-branch-tracking

[omerap12]

Yes, I understand your concern. We use tag tracking because our configuration repo is not updated very often. How do you suggest we address this issue then?

[andrii-korotkov-verkada]

I didn't work with tag tracking, but in theory it sounds like your original approach described here can work well.

[omerap12]

Great, so can someone review?

[andrii-korotkov-verkada]

Sorry, just got back to it. I think we need a more generic solution supporting multi-source apps as well. How about we export some json about source/sources and then post-process it?