Open OpenGuidou opened 3 days ago
Hello, can I take this issue? 🙂 @OpenGuidou can you confirm that we should have either values or valuesString (both can't be used at the same time).
Sure, go ahead !
It's Indeed a good idea to check only one is provided
Thanks! /assign
I took a look at the issue. I am not sure that it is a good idea to add the valuesString
field since it is redundant. Why not using in this way?
spec:
goTemplate: true
generators:
- list:
elements:
- cluster: engineering-dev
url: https://kubernetes.default.svc
envs:
- staging
- prod
selector:
matchExpressions:
- key: env
operator: In
values: [`{{- range $index, $env := .envs }}{{ if $index }}, {{ end }}"{{ $env }}"{{- end }}`]
The thing is we want to be as much close to the native Kubernetes API as possible. The struct for the matchExpressions
does not include the valuesString
field.
You would still end up with a list of a single string.
The idea would be to extend the metav1 LabelSelector, and convert the valuesString
to values
before applying the selector
Summary
With the current state of applicationset templating, it's not possible to provide values as a list in a selector
matchExpressions
values, coming from variables defined in the generator or from another generator.Motivation
Let's take the example of this applicationset:
It's not possible to provide the
envs
variable in the selectorvalues
.Proposal
I would propose to add a field in the matchExpression, to support a list of values as string:
This would be a comma-separated list, as a string, that could be filled using templating functions: