Description
The Problem
Previously, I used the application.instanceLabelKey: argocd.argoproj.io/instance
configuration to have argocd.argoproj.io/instance=my-ops-repo
labels on my ArgoCD Applications.
By doing this, I was able to restrict the default subscriptions to all the applications in my main repo by using selector: argocd.argoproj.io/instance=my-ops-repo
.
In ArgoCD 3.0, annotation based tracking is strongly recommended and is now used as the default.
Therefore, following the recommended changes would break this selector and my notifications.
To remedy this, annotation+label
can be used "for informational purposes" and to support tools that require it.
There's a workaround, why bother changing?
I would prefer to follow the emphasized default. The notifications engine seems to be the only component that currently prevents me from making the switch.
Given that ArgoCD Notifications is, as the name suggests, an official project, basic use cases shouldn't require switching to a sub-par solution meant for tools that didn't bother updating yet. Imo, the notifications engine should remain a first-class citizen staying up to date with changes to the upstream ArgoCD project and actively supporting them.
Proposed solution
Add an annotationSelector
field to the DefaultSubscription
. Since plain =
matching will not work anymore due to the new format containing significantly more information (e.g. my-ops-repo:argoproj.io/Application:argocd/myapp
instead of just my-ops-repo
), some kind of other filtering methods will have to be introduced. A contains
or Regex-based one would do just fine.
The syntax could follow the PromQL matching operators:
=
: Select labels that are exactly equal to the provided string.!=
: Select labels that are not equal to the provided string.=~
: Select labels that regex-match the provided string.!~
: Select labels that do not regex-match the provided string.
Given the "exactly equal" operator being =
, this would both remain backwards compatible and feel familiar to engineers in this space while supporting my use case and many more.