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

Add devfile validation #301

Merged
merged 14 commits into from
Feb 2, 2021
Merged

Add devfile validation #301

merged 14 commits into from
Feb 2, 2021

Conversation

maysunfaisal
Copy link
Member

@maysunfaisal maysunfaisal commented Jan 13, 2021

What does this PR do?

Implement the consolidated validations documented in https://github.com/devfile/api/blob/master/pkg/validation/validation-rule.md

What issues does this PR fix or reference?

Fixes #151

Is your PR tested? Consider putting some instruction how to test your changes

Yes, new go tests

Docs PR

Copy link
Contributor

@amisevsk amisevsk left a comment

Choose a reason for hiding this comment

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

Generally looks good, a few comments regarding test cases.

Comment on lines 44 to 95
name: "Case 2: Invalid postStart and postStop events",
events: v1alpha2.Events{
WorkspaceEvents: v1alpha2.WorkspaceEvents{
PostStart: []string{
"apply1",
"exec2",
"compositeExecApply",
},
PostStop: []string{
"apply12",
"exec2",
"compositeExecApply",
},
PreStart: []string{
"apply12",
"exec2",
"compositeExecApply",
},
PreStop: []string{
"apply12",
"exec2",
"compositeExecApply",
},
},
},
wantErr: true,
},
Copy link
Contributor

Choose a reason for hiding this comment

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

This is an overly-large test case IMO -- we expect a dozen errors to be returned here, but only check that any error is returned; we could pass this test by e.g. checking only that there are no exec commands in preStart.

eventType string
eventNames []string
wantErr bool
wantErrMsg string
Copy link
Contributor

Choose a reason for hiding this comment

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

wantErrMsg is unused in test cases.

Comment on lines 143 to 191
{
name: "Case 5: Invalid postStart events - Exec and Composite Mixed Commands",
eventType: postStart,
eventNames: []string{
"exec1",
"exec2",
"compositeExecApply",
},
wantErr: true,
},
{
name: "Case 6: Invalid preStop events - Non-Exec and Composite Exec Commands",
eventType: preStop,
eventNames: []string{
"exec1",
"apply2",
"compositeOnlyExec",
},
wantErr: true,
},
Copy link
Contributor

Choose a reason for hiding this comment

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

These tests are unclear to me; could we rename the tests to be more precise in what the expected problem is? E.g.

Case 5: Invalid postStart events - Composite command contains non-exec command
Case 6: Invalid preStop events - Non-exec command in events

name: "Case 2: Invalid Starter Project",
starterProjects: []v1alpha2.StarterProject{
generateDummyGithubStarterProject("project1", "origin", map[string]string{"origin": "originremote", "test": "testremote"}),
generateDummyGithubStarterProject("project2", "origin", map[string]string{"origin": "originremote", "test": "testremote"}),
Copy link
Contributor

Choose a reason for hiding this comment

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

This test would be clearer if there was only one starter project.

Comment on lines 24 to 28
{
name: "Case 3: string with numbers and character",
arg: "12_34",
wantResult: false,
},
Copy link
Contributor

Choose a reason for hiding this comment

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

Should add a testcase for arg: "0xff" to catch in case someone tries to use ParseInt instead of Atoi. Note also that underscores in IDs are not allowed by regex.

}
return false
func isInt(str string) (bool, error) {
match, err := regexp.MatchString("^[0-9]+$", str)
Copy link
Contributor

Choose a reason for hiding this comment

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

Two minor issues here:

  1. Regex won't match 10-10; if you want to check that at least one letter exists, just check "[a-zA-Z]"
  2. Avoid returning an error by using
    var alphaRegexp = regexp.MustCompile(`[a-zA-Z]`)
    
    at the top of the file.

Copy link
Member Author

Choose a reason for hiding this comment

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

+1 on point 2, thx

On point 1, I just chatted with Stephanie who wrote the initial doc for validation and it seems to her 10-10 would be a valid id. I just tried it out and it looks Kube seems to be happy with it.
Looks like we only want to restrict 1234. Do you agree or have a counter argument?

Copy link
Contributor

@amisevsk amisevsk Jan 25, 2021

Choose a reason for hiding this comment

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

If 10-10 is valid but 1234 is not, I wonder where the restriction is coming from. For what it's worth, 1234 is a valid identifier in k8s as well (you have to quote it in yaml otherwise it's interpreted as an integer).

The only checks for "not all numbers" I know of are

  1. Places that use RFC1035 DNS labels (must start with an alphabetic character) -- this regex doesn't match this as 1a passes but is invalid.
  2. Port names, for which 10-10 is invalid

In this case, what is the isInt check being used for specifically? I tried applying a DevWorkspace with ids like "1234" littered throughout and I didn't run into any issues -- the DevWorkspace operator correctly named a container 1234.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually I wasnt able to create a svc with 1234/12-34. Not sure what resource the DevWorkspace was creating 🤔. I even quoted it in yaml :

The Service "1234" is invalid: metadata.name: Invalid value: "1234": a DNS-1035 label must consist of lower case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character (e.g. 'my-name',  or 'abc-123', regex used for validation is '[a-z]([-a-z0-9]*[a-z0-9])?')

But anyhow, I think we can remove this restriction. I confirmed and it seems like port name cannot take either 1234/12-34 like you suggested and linked. And the library generator is already handling this for container port names from devfile.

Command IDs are not representative of any Kube resource and this just leaves us with Component name. I was able to create a pod with container named "1234"/"12-34".

WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense to me, it seems like isInt is unnecessary (I believe the 1234 svc name is covered by in-schema regexes)

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated! I have also addressed the remaining unresolved conversations.

@maysunfaisal
Copy link
Member Author

@amisevsk Any updates on the addressed commits? Thx!

Copy link
Contributor

@amisevsk amisevsk left a comment

Choose a reason for hiding this comment

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

Overall LGTM, a few leftover minor nits.

)

// ValidateCommands validates the devfile commands and checks:
// 1. the command id is not all numeric
Copy link
Contributor

Choose a reason for hiding this comment

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

Doc is out of date since we removed the isInt requirement.

// 1. the command id is not all numeric
// 2. there are no duplicate command ids
// 3. the command type is not invalid
// 4. commands belonging to a specific group obeys the rule of 1 default command
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe clearer wording:

Suggested change
// 4. commands belonging to a specific group obeys the rule of 1 default command
// 4. if a command is part of a command group, there is a single default command

maysunfaisal and others added 10 commits February 1, 2021 15:40
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Stephanie <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Stephanie <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Stephanie <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
Signed-off-by: Maysun J Faisal <[email protected]>
@maysunfaisal
Copy link
Member Author

@amisevsk thanks for those nit reviews! 🙌 I've addressed them!

Copy link
Contributor

@amisevsk amisevsk left a comment

Choose a reason for hiding this comment

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

Approving again to say LGTM! Thanks for your patience @maysunfaisal

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: amisevsk, maysunfaisal
To complete the pull request process, please assign after the PR has been reviewed.
You can assign the PR to them by writing /assign in a comment when ready.

The full list of commands accepted by this bot can be found 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

@maysunfaisal
Copy link
Member Author

@amisevsk no thank you for the thorough review! Appreciate it.

@maysunfaisal maysunfaisal merged commit 6424f41 into devfile:master Feb 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consolidate dev workspace & odo validations
5 participants