-
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
Fix enum validation with multiple param references #7481
Fix enum validation with multiple param references #7481
Conversation
Fixes [tektoncd#7476][7476]. TEP-0144 requires that the pipeline-level `enum` must be a subset of referenced task-level `enum`. Prior to this commit, the enum subset validation logic assumes that a task-level param only referenced only one pipeline-level `enum`, and does not support scenario where multiple pipeline-level `enums` are referenced (e.g., "$(params.p1) and $(params.p2)"). This commit adds the handling logic for such compound references, skipping the subset validation in this scenario as there is no directly associated params at pipeline level. /kind bug [7476]: tektoncd#7476
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/retest |
params: | ||
- name: message1 | ||
enum: ["v1"] | ||
- name: message2 | ||
enum: ["v2"] | ||
tasks: | ||
- name: task1 | ||
params: | ||
- name: message | ||
value: "$(params.message1) and $(params.message2)" | ||
taskSpec: | ||
params: message | ||
enum: [...] # the message enum is not required to be a subset of message1 or message2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious, if for the task, we have an enum that requires a url to beabc/foo
, and the pipeline passes a $(params.url-part1)/$(params.url-part2)
param to the task's param.
The PR will skip the validation right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. There are 2 kinds of check we do
- Validate user input against enums. At pipeline level, we will validate
message1
andmessage2
individually; at task-level, we validate the value ofmessage
is in it own enum (the compound value). This PR does not change this behavior. - Subset validation: prior to the change, we require that the pipeline-level param enum must be a subset of the task-level enum referencing it. If a task-level
param
referenes a single pipeline-levelparam
, it is easy and we still validate it. However, if it references multiple pipeline-level params, like this one, we will skip the subset validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh this is the subset validaition, I thought it is the first one
Thanks for speedy solution, can we merge this fix @QuanZhang-William :) , as I needed to workaround (like using |
Hi @dohoangkhiem 👋 . I have pinged some reviewers to review and merge this PR. As a workaround, would disabling the param enum feature by setting |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JeromeJu, Yongxuanzhang The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Changes
Fixes #7476. TEP-0144 requires that the pipeline-level
enum
must be a subset of referenced task-levelenum
.Prior to this commit, the enum subset validation logic assumes that a task-level param only referenced only one pipeline-level
enum
, and does not support scenario where multiple pipeline-levelenums
are referenced (e.g., "$(params.p1) and $(params.p2)").This commit adds the handling logic for such compound references, skipping the subset validation in this scenario as there is no directly associated params at pipeline level.
/kind bug
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes