-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Correctly capture all params and validate against correct ParamSpec with substitutions considered #4879
Comments
Pinging @Yongxuanzhang @chuangw6 |
For array params and results, maybe we can let user follow these syntax, this can distinguish the usage of different types.
or
|
Discussed with @Yongxuanzhang offline. Similarly when providing object type param with the object type param variable (from pipeline spec's params) or the object type result variable from a task, it would make more sense to let users follow yaml's dictionary syntax as well (surrounding the variable with
params:
- name: gitrepo
value: {$(params.myObject[*])}
params:
- name: gitrepo
value: {$(tasks.TASK_NAME.results.OBJECT_RESULT_NAME[*])}
params:
- name: gitrepo
value: $(params.myObject[*]) CaveatWhen providing value with map[$(params.myObject[*]):] This will lead us to add additional checks for the special case when implementing validation and param apply/replacement. Because we need to distinguish between explicit definition (like the following example) and using variables. params:
- name: gitrepo
value:
url: abc.com
commit: xxxx The unmarshal result for map[url:"abc.com", commit: "xxxx"] Thoughts
params:
- name: gitrepo
value:
url: abc.com
commit: "$(param.aStringTypeParam)" |
@ywluogg @chuangw6 I'm trying to understand why all substituted params are considered string type....do you have an example/link to your branch where I can see the code? Using the [] and {} for values seems like the technically correct thing to do though combining that with [*] makes the syntax a bit hard to follow. |
None of them are implemented yet, but based on the current code in Regarding to what Chuang suggested, I also have the concern that it would be making syntax a bit hard to follow.
Then what's in params that would be:
|
I don't quite understand this part. Can you explain more? params:
- name: gitrepo
value:
url: abc.com
commit: xxxx And my previous post only suggests surrounding with |
Yes, UnmarshalJSON will set type to be string if the first char of raw json doesn't start with |
I discussed with @chuangw6 yesterday and I lean to only use
not
Same for |
I meant to say the value of an object already starts with the json schema that looks like (example in tep75):
In params, if you add another bracket as you suggested in your example:
It actually is the following after substitution:
I think this is the complexity that Dibyo and I think would be confused to users. Or is this not what you are suggesting?
AFAIU, this works because this format
in OpenAPI yaml to json transition, it is referring to a object schema, but what you are suggesting:
is not recognized as an object. I think the example in your mind is this:
I don't think
is referring to the above example. In short, I believe what you are suggesting is adding an extra |
Ok, just to make sure I'm understanding this properly, if we have the following param inside a params:
- name: gitrepo
value: $(params.gitrepo[*]) and the value of params:
- name: gitrepo
value:
url: https://github.com/tektoncd/pipeline
commit: "6f633b2"
params:
- name: gitrepo
value: "{\"url\": \"https://github.com/tektoncd/pipeline\", \"commit\": \"6f633b2\"}"
|
Chatted with @ywluogg @chuangw6 @Yongxuanzhang the issue was that the |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
I think we address this one. |
@Yongxuanzhang: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Feature request
Recently, we have ArrayOrString implementing UnmarshalJSON for json.Unmarshaller interface. It will set the ArrayOrString.Type to be string when the data starts with a symbol other than
{
,"
or[
. It means that any substituted params will be considered as string type.When implementing
'$(params.paramvalue[*])'
for both arrays and objects for params, this becomes problematic, as current code will fail at checking parameter type at wrongTypeParamsNames in validate_resources.go, as the param will be considered as string.An example can be:
If the params being passed is arrays (with the assumption that now the object in the array is strings), and the substituted type is also arrays of strings, it can also be using the following way for substitution:
We need to be able to pass the check when param is a substitution of another param or results that's either a array or object in wrongTypeParamsNames and be able to capture all the param and paramSpec pairs by tracing back the variable reference back to its actual type in validateParams(), when we substitute params with objects and arrays as a whole.
Use case
The text was updated successfully, but these errors were encountered: