-
Notifications
You must be signed in to change notification settings - Fork 65
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
Conversation
053441e
to
692a917
Compare
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.
Generally looks good, a few comments regarding test cases.
pkg/validation/events_test.go
Outdated
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, | ||
}, |
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.
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
.
pkg/validation/events_test.go
Outdated
eventType string | ||
eventNames []string | ||
wantErr bool | ||
wantErrMsg string |
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.
wantErrMsg
is unused in test cases.
pkg/validation/events_test.go
Outdated
{ | ||
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, | ||
}, |
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.
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
pkg/validation/projects_test.go
Outdated
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"}), |
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.
This test would be clearer if there was only one starter project.
pkg/validation/utils_test.go
Outdated
{ | ||
name: "Case 3: string with numbers and character", | ||
arg: "12_34", | ||
wantResult: false, | ||
}, |
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.
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.
pkg/validation/utils.go
Outdated
} | ||
return false | ||
func isInt(str string) (bool, error) { | ||
match, err := regexp.MatchString("^[0-9]+$", str) |
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.
Two minor issues here:
- Regex won't match
10-10
; if you want to check that at least one letter exists, just check"[a-zA-Z]"
- Avoid returning an error by using
at the top of the file.
var alphaRegexp = regexp.MustCompile(`[a-zA-Z]`)
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.
+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?
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.
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
- Places that use RFC1035 DNS labels (must start with an alphabetic character) -- this regex doesn't match this as
1a
passes but is invalid. - 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
.
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.
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?
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.
Makes sense to me, it seems like isInt
is unnecessary (I believe the 1234
svc name is covered by in-schema regexes)
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.
Updated! I have also addressed the remaining unresolved conversations.
@amisevsk Any updates on the addressed commits? Thx! |
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.
Overall LGTM, a few leftover minor nits.
pkg/validation/commands.go
Outdated
) | ||
|
||
// ValidateCommands validates the devfile commands and checks: | ||
// 1. the command id is not all numeric |
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.
Doc is out of date since we removed the isInt
requirement.
pkg/validation/commands.go
Outdated
// 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 |
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.
Maybe clearer wording:
// 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 |
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]>
@amisevsk thanks for those nit reviews! 🙌 I've addressed them! |
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.
Approving again to say LGTM! Thanks for your patience @maysunfaisal
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: amisevsk, maysunfaisal 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 |
@amisevsk no thank you for the thorough review! Appreciate it. |
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