You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 12, 2023. It is now read-only.
While writing a new E2E test, I happened to create an ApplicationSet resource that produced invalid Argo CD applictions:
I created the ApplicationSet, and the ApplicationSet controller correctly created the Application.
However, the created Application was invalid.
Argo CD correctly complained that application destination can't have both name and server defined: in-cluster.
It was correct for Argo CD to complain about this, because I did, in fact, have both a name and a server defined in my ApplicationSet. The ApplicationSet I had defined was producing an invalid Application via the templating process.
The ApplicationSet controller should never create invalid Argo CD Applications (thus leaving it up to Argo CD to deal with that), it should instead detect if an ApplicationSet will produce an invalid Application, and rather than creating the Application it should instead log an error to the console (and, in the future, report a message as a condition within the status field).
This invalid Application also prevented Argo CD from deleting the Application, with this message printed on delete (eg via the finalizer): Unable to delete application resources: application destination can't have both name and server defined: in-cluster
This was the invalid Application that was produced:
While writing a new E2E test, I happened to create an
ApplicationSet
resource that produced invalid Argo CD applictions:application destination can't have both name and server defined: in-cluster
.It was correct for Argo CD to complain about this, because I did, in fact, have both a name and a server defined in my ApplicationSet. The ApplicationSet I had defined was producing an invalid Application via the templating process.
The ApplicationSet controller should never create invalid Argo CD
Application
s (thus leaving it up to Argo CD to deal with that), it should instead detect if anApplicationSet
will produce an invalidApplication
, and rather than creating theApplication
it should instead log an error to the console (and, in the future, report a message as a condition within the status field).This invalid
Application
also prevented Argo CD from deleting the Application, with this message printed on delete (eg via the finalizer):Unable to delete application resources: application destination can't have both name and server defined: in-cluster
This was the invalid Application that was produced:
The text was updated successfully, but these errors were encountered: