-
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
Remove validation of parameter variables after substitution #4835
Conversation
The following is the coverage report on the affected files.
|
/ok-to-test |
The following is the coverage report on the affected files.
|
/assign @ywluogg |
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.
Can you add more tests to reflect the changes?
nit: please fix typo in title -- "declared", not "decalred" :-) |
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 @Aleromerog!
A few comments:
- This change should likely be made for PipelineRuns as well
- Take a look at our commit message standards; there's a great example commit message there you can use. Here's a rewording I might suggest:
Title: Remove validation of parameter variables after substitution
Message: This commit removes validation for fields containing a parameter variable
after the parameter value has already been substituted.
This is done to allow parameter values to contain literal strings like $(params.foo); for example, in #4690. <etc>
@@ -79,7 +79,7 @@ func validateResults(ctx context.Context, results []TaskResult) (errs *apis.Fiel | |||
|
|||
// a mount path which conflicts with any other declared workspaces, with the explicitly | |||
// declared volume mounts, or with the stepTemplate. The names must also be unique. | |||
func validateDeclaredWorkspaces(workspaces []WorkspaceDeclaration, steps []Step, stepTemplate *StepTemplate) (errs *apis.FieldError) { | |||
func ValidateDeclaredWorkspaces(workspaces []WorkspaceDeclaration, steps []Step, stepTemplate *StepTemplate) (errs *apis.FieldError) { |
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.
Exported func's comments should start with their name, see this and other functions for reference. Same with other functions.
If not you will fail the build check
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
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 Alejandro this is looking good!
Using the example from the linked issue but with a Pipeline instead of a Task:
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: some-pipeline
namespace: my-ns
spec:
params:
- name: input
tasks:
- name: foo
taskSpec:
params:
- name: input
value: $(params.input)
steps:
- name: print
image: alpine
script: |
echo $(params.input)
---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
name: some-pipeline-run-2
namespace: my-ns
spec:
pipelineRef:
name: some-pipeline
serviceAccountName: tekton-triggers-admin
params:
- name: input
value: '{"key": "$(params.a)"}'
we may run into a similar issue when validating the pipelinespec.
(not sure if this is the case or not but it's worth looking into and adding a test case for this or a note about this in your commit message/PR description)
@@ -48,6 +48,15 @@ func (ts *TaskSpec) Validate(ctx context.Context) (errs *apis.FieldError) { | |||
if len(ts.Steps) == 0 { | |||
errs = errs.Also(apis.ErrMissingField("steps")) | |||
} | |||
|
|||
if config.IsSubstituted(ctx) { | |||
// Validate the task's workspaces only. |
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.
What's the reason to validate only a Task's workspaces, and not include any of the other non-parameter-related validation steps? (genuinely asking, not suggesting this should necessarily be changed)
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.
Also, I think in the linked issue, if the value passed for the parameter was '{"key": "$(workspaces.a)"}' instead of '{"key": "$(params.a)"}' (or similar) we'll run into a similar issue with workspace validation-- but maybe out of scope for this PR
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 think that the initial reason that a second validation were added was from #3786. And it ended up calling to validate all again instead of just workspaces
Thanks for the feedback! I changed Pipeline to have same behaviour (to validate only workspaces on the second validation) but apparently there were some test cases that were failing because they were waiting to validate the entire thing. Maybe we can create other issue and discuss further about adding it to pipelines as well if necessary. |
The following is the coverage report on the affected files.
|
Sounds good; in this case, I would just write up your findings in a comment on #4690, and update the commit message + PR description to indicate that tackling this on PipelineRun is out of scope for this commit/PR |
This commit removes validation for fields containing a parameter variable after the parameter value has already been substituted in TaskRun and PipelineRun. This is done to allow parameter values to contain literal strings like $(params.a); for example, in tektoncd#4690.
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lbernick, vdemeester 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 |
/retest |
Changes
This commit removes validation for fields containing a parameter variable
after the parameter value has already been substituted in TaskRun and PipelineRun.
This is done to allow parameter values to contain literal strings like $(params.a); for example, in #4690.
Removing validation of parameters variables after substitution for PipelineRun is out of the scope of
this PR, since it needs more discussion/analysis
Note: Passing $(params.x) are not longer being validated after substitution. However, in order to work as expected referring to #4690 you need to scape special characters to avoid problems with bash or zsh, like the following:
'\{\"key\": \"\$\(params.a\)\"\}'
or
"{'key': '$(params.a)'}"
to get the expected output:
{"key": "$(params.a)"}
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
(if there are no user facing changes, use release note "NONE")
Release Notes