-
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
Move validation from pipelinespec
to pipelinerunspec
when propagating parameters
#5291
Move validation from pipelinespec
to pipelinerunspec
when propagating parameters
#5291
Conversation
/kind bug |
The following is the coverage report on the affected files.
|
/hold Wait for PR to be merged first |
91e9714
to
1280803
Compare
/hold cancel |
The following is the coverage report on the affected files.
|
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.
thanks @chitrangpatel!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jerop 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 |
1280803
to
14f4901
Compare
The following is the coverage report on the affected files.
|
/retest timeout flake again 🙁 |
@chitrangpatel: The
The following commands are available to trigger optional jobs:
Use 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. |
/retest @chitrangpatel |
@@ -38,6 +39,7 @@ func (p *Pipeline) Validate(ctx context.Context) *apis.FieldError { | |||
if apis.IsInDelete(ctx) { | |||
return nil | |||
} | |||
ctx = config.SetValidateParameterVariablesAndWorkspaces(ctx, true) |
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 should have mentioned this on the other PR, but this name is confusing to me. Just based on the name alone, it's not really clear what changes when you set this. It feels like it's saying "ok, validate parameters and workspaces" in general, which seems like something you'd never actually want to turn off. Could we get this a more clear name to better signify exactly what it's doing?
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.
Yes, that's right. How about I have a flag that is defaulted to true
and we only call it when we intend to make it false
?
e.g.
we could have config.DoNotValidateParameterVariablesAndWorkspaces(ctx)
which would set it the underlying context field to false
.
We also have a function config.ValidateParameterVariablesAndWorkspaces(ctx)
which returns a true
or false
based on the value of the context field. This function is called by task_validation
to decide whether to validate parameters and workspaces. We can have it return true
by default.
Does that look like a good solution?
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'd really like the name to be more clear than ValidateParameterVariablesAndWorkspaces
- that name is just too vague. What does it relate to? Which parameter variables and workspaces? If we're just using it for parameter propagation cases, it feels like it would make more sense to have the name be something regarding parameter propagation validation, i.e., why we're setting this flag, not what the result of setting this flag is.
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 see what you mean. Its trying to skip validation when it does not contain the full information. e.g. When propagating parameters, a user could provide the params at the task run or the pipeline run level and directly call them in the steps. However, when we validate the underlying taskSpec or pipelineSpec, we don't have these params declared there and so the web hook would throw an error. This flag allows us to specify where to skip validation of params due to lack of information.
I could call the it SkipValidationDueToPropagatedParametersAndWorkspaces
(a bit of a mouthful, but ok I guess)?
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.
That would definitely be better, yeah.
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 will make the appropriate changes.
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.
@abayer done! Thanks for the suggestion.
14f4901
to
d529a7b
Compare
The following is the coverage report on the affected files.
|
…ting parameters Prior to this, propagating parameters only skipped webhook validation for params defined in script. As a result, when users tried to propagate params to other fields like `args` or `command`, etc. an webhook validation was raised. This PR address this issue.
d529a7b
to
5f503b5
Compare
The following is the coverage report on the affected files.
|
/retest |
/lgtm |
It seems that some cc @Yongxuanzhang @chitrangpatel Could you please help confirm here? |
I agree. I don't recall which PR was merged first. There is backwards compatibility which is why the tests work. However, we should make it ParamValue. I can do that in one shot in a separate PR. |
Thanks @chitrangpatel |
Changes
Prior to this, propagating parameters only skipped webhook validation for params defined in script. As a result, when users tried to propagate params to other fields like
args
orcommand
, etc. an webhook validation was raised. This PR address issue #5141. This PR addresses validations inpipelinespec
andpipelinerunspec
. The changes for validations intaskspec
andtaskrunspec
are in a separate PR.Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes