Skip to content
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

Added validation for parameters with bracket notation #4833

Merged
merged 1 commit into from May 9, 2022

Conversation

chitrangpatel
Copy link
Member

@chitrangpatel chitrangpatel commented May 4, 2022

Added validation for parameters with bracket notation.

Prior to this, when supplied parameter name was not the same as that
called in the step, webhook raised an error when using the dot notation
as expected. However, it did not when using the bracket notation.

Changes

Updated the unit tests to also check for valid bracket notations.
This PR addresses issue #4787

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

  • Docs included if any changes are user facing
  • Tests included if any functionality added or changed
  • Follows the commit message standard
  • Meets the Tekton contributor standards (including
    functionality, content, code)
  • Release notes block below has been filled in
    (if there are no user facing changes, use release note "NONE")

Release Notes

Added validation for parameters with bracket notation

@tekton-robot tekton-robot added the release-note Denotes a PR that will be considered when it comes time to generate release notes. label May 4, 2022
@tekton-robot tekton-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 4, 2022
@tekton-robot
Copy link
Collaborator

Hi @chitrangpatel. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

@chitrangpatel chitrangpatel reopened this May 4, 2022
@chitrangpatel chitrangpatel marked this pull request as draft May 4, 2022 16:47
@tekton-robot tekton-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels May 4, 2022
@tekton-robot tekton-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. and removed size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels May 4, 2022
@chitrangpatel chitrangpatel marked this pull request as ready for review May 4, 2022 17:18
@tekton-robot tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 4, 2022
@tekton-robot
Copy link
Collaborator

@chitrangpatel: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/ok-to-test

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.

Comment on lines 50 to 75
for _, v := range vs {
v = strings.TrimSuffix(v, "[*]")

// contains any character except "_a-zA-Z0-9.-"?
re := regexp.MustCompile(`[^_a-zA-Z0-9.-]`)
matches := re.FindAllStringSubmatch(v, -1)
if len(matches) > 0 {
return &apis.FieldError{
Message: fmt.Sprintf("Invalid variable name format in value: %q. Must not contain any character other than a-z, A-Z, 0-9, or . _ -", value),
// Empty path is required to make the `ViaField`, … work
Paths: []string{""},
}
}

// starts with anything except _, a-z, A-Z?
re = regexp.MustCompile(`^[^_a-zA-Z].*`)
matches = re.FindAllStringSubmatch(v, -1)
if len(matches) > 0 {
return &apis.FieldError{
Message: fmt.Sprintf("Invalid variable name format in value: %q. Must not start with any character other than a-z, A-Z, 0-9, or _", value),
// Empty path is required to make the `ViaField`, … work
Paths: []string{""},
}
}
}
}
Copy link
Member

@chuangw6 chuangw6 May 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the three steps we discussed (pasted below), in step2, I think we don't need to do any validation here inside ValidateVariableP. Because validation against the param names specified in ParamSpec should happen inside task_validation.go's validateVariables function, which is step 1.

Step1: validate the format of param names at the beginning of validateVariables in pkg/apis/pipeline/v1beta1/task_validation.go (Implemented here #4799)

Step2: change regex to extract NAME for $(params.<NAME>) and NAME for $(params["<NAME>"]) without validating anything

Step3: Check if the extracted string is one of the param names declared in param spec. (exists already)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be ok now @chuangw6 . Let me know otherwise.

@afrittoli
Copy link
Member

/ok-to-test

@tekton-robot tekton-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels May 4, 2022
@afrittoli
Copy link
Member

Release Notes

NONE

Perhaps its worth adding a note in the release notes?

@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/substitution/substitution.go 43.8% 65.0% 21.2

@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/substitution/substitution.go 43.8% 54.5% 10.7

@chitrangpatel
Copy link
Member Author

chitrangpatel commented May 4, 2022

Release Notes

NONE

Perhaps its worth adding a note in the release notes?

@afrittoli Since there were no user facing changes, I skipped it as suggested by the Submitter Checklist section. I added one now anyway 🙂

@chitrangpatel
Copy link
Member Author

/retest

@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 5, 2022
@lbernick
Copy link
Member

lbernick commented May 5, 2022

@chitrangpatel would you mind changing the PR title to something more descriptive?
In addition, a more informative release note could be something like "Added validation for parameters with bracket notation"

@chitrangpatel chitrangpatel changed the title Issue 4787 Issue-4787-Missing-validation-when-referencing-unknown-params-with-bracket-notation May 5, 2022
@chitrangpatel
Copy link
Member Author

@chitrangpatel would you mind changing the PR title to something more descriptive?
In addition, a more informative release note could be something like "Added validation for parameters with bracket notation"

Done!

@chuangw6 chuangw6 mentioned this pull request May 6, 2022
5 tasks
@lbernick
Copy link
Member

lbernick commented May 9, 2022

@chitrangpatel would you mind also changing the commit message title and PR title to be "Add validation for parameters with bracket notation"? other than that looks good :)

@chitrangpatel chitrangpatel changed the title Issue-4787-Missing-validation-when-referencing-unknown-params-with-bracket-notation Added validation for parameters with bracket notation May 9, 2022
@chitrangpatel
Copy link
Member Author

@chitrangpatel would you mind also changing the commit message title and PR title to be "Add validation for parameters with bracket notation"? other than that looks good :)

Done!

@lbernick
Copy link
Member

lbernick commented May 9, 2022

@chitrangpatel would you mind also changing the commit message title and PR title to be "Add validation for parameters with bracket notation"? other than that looks good :)

Done!

don't forget the commit message title!

Prior to this, when supplied parameter name was not the same as that
called in the step, webhook raised an error when using the dot notation
as expected. However, it did not when using the bracket notation.

Updated the unit tests to also check for valid bracket notations.
@chitrangpatel
Copy link
Member Author

@chitrangpatel would you mind also changing the commit message title and PR title to be "Add validation for parameters with bracket notation"? other than that looks good :)

Done!

don't forget the commit message title!

Done now. (I accidentally changed the PR's first line thinking it was the title of the commit message).

@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/substitution/substitution.go 43.8% 54.5% 10.7

@chitrangpatel
Copy link
Member Author

/retest

@lbernick
Copy link
Member

lbernick commented May 9, 2022

/lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants