-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrading to 2.12 breaks ability to use .namespace in ApplicationSet List Generator #19423
Comments
I think I heard someone else say they had trouble with parameters applying in nested generators. Can you create a unit test to reproduce the issue? That would be a good first step in figuring out what broke the templating. |
I got similar problem which may be related. I get no error in the logs but our applicationset dosent seem to pick up new deployment. Like @rknightion 2.11.7 works without problems |
it is related to #18906, problem is |
@allevimi does hard-coding the project field solve the error? |
didn't test it, but I think that hardcoding a valid one, it will works var project string
if strings.Contains(appSet.Spec.Template.Spec.Project, "{{") {
project = appSetGenerator.Git.Template.Spec.Project
} else {
project = appSet.Spec.Template.Spec.Project
}
appProject := &argoprojiov1alpha1.AppProject{}
if err := client.Get(context.TODO(), types.NamespacedName{Name: appSet.Spec.Template.Spec.Project, Namespace: appSet.Namespace}, appProject); err != nil {
return nil, fmt.Errorf("error getting project %s: %w", project, err)
} I'm not a GO guru, but it seems that only checks if |
Ah 100%. @ishitasequeira is there any way we can rework the signature verification logic to allow templating the project field? Maybe we can just document a limitation like "if you need signature verification, you can't template the project field"? |
In the meantime if anyone has time to write up a PR making that change so that we can evaluate our options, I'd appreciate it! |
We are experiencing the same error message when using git generator files. Adding here as opposed to create a new issue as we see the same error. Please let me know if you want it created in a separate issue. Describe the bug When deploying an applicationset similar to: apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: my-appset
namespace: canaria-prod
spec:
goTemplate: true
generators:
- git:
repoURL: {{ .Values.repository.url | quote }}
revision: {{ .Values.repository.revision | quote }}
files:
- path: '{{ .Values.path }}/*.yaml'
template:
metadata:
name: '{{ "{{" }}.path.filename | trimSuffix ".yaml" {{ "}}" }}'
spec:
project: canaria-prod
destination:
name: in-cluster
namespace: canaria-prod
...... ApplicationSet has been deployed with namespace and project as being hardcoded and templated. Both resulted in the same error as shown below. We get errors in the logs: Version |
I also bumped into this error while upgrading to 2.12.0, the solution so far is to hardcode the project name value |
@MarcStorm I think you have a different cause, because you have hardcoded your project value; it seems that |
@allevimi - Note that I mentioned we see the same behaviour regardless of templating or hardcoding the project name. Our AppProject are managed in a separate namespace, called core-argocd. I should emphasise that the same setup/configuration works with v. 2.11.3 kubectl --namespace canaria-prod get appprojects.argoproj.io
No resources found in canaria-prod namespace.
kubectl get appprojects.argoproj.io -A
NAMESPACE NAME AGE
core-argocd canaria-prod 22d |
@MarcStorm my bad :) appProject := &argoprojiov1alpha1.AppProject{}
if err := client.Get(context.TODO(), types.NamespacedName{Name: appSet.Spec.Template.Spec.Project, Namespace: appSet.Namespace}, appProject); err != nil {
return nil, fmt.Errorf("error getting project %s: %w", project, err)
} |
Yep, there are two bugs here.
Would someone be willing to open a PR for the second bug? Should be a one-line fix (plus any tests needed). |
@crenshaw-dev happy to take a stab at it - just to confirm, this is the function in question, correct? argo-cd/applicationset/generators/git.go Line 70 in 5ccea0d
|
Yep! |
So @crenshaw-dev , after digging around for a bit, I'm thinking the |
@cilindrox at a glance, that looks reasonable. |
Keeping open to track the appsets-in-any-namespace fix. |
@cilindrox are you working on the fix for the 2nd bug mentioned here? If not, I could take a look at it. |
We are also blocked in deploying new applications using the git generator in applicationSets. We use Thanks for the fix, is there an estimated time on when is it going to be released? |
This should be fixed in v2.12.1. |
Checklist:
Describe the bug
When deploying an applicationset similar to:
We get errors in the logs:
and
This worked fine for us in v2.11.7.
To Reproduce
Use a similar applicationset to the above
Expected behavior
The applicationset provisions applications against a project based on the {{.namespace}} value generated by the list generator
Version
2.12.0
The text was updated successfully, but these errors were encountered: