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

Consolidate dev workspace & odo validations #151

Closed
maysunfaisal opened this issue Oct 5, 2020 · 4 comments · Fixed by #301
Closed

Consolidate dev workspace & odo validations #151

maysunfaisal opened this issue Oct 5, 2020 · 4 comments · Fixed by #301
Assignees
Labels
area/library Common devfile library for interacting with devfiles kind/enhancement New feature or request

Comments

@maysunfaisal
Copy link
Member

Following the Devfile discussion, it was decided that the devfile validation would reside in devfile/api since the schema and go structs reside in devfile/api.

This issue tracks the work where we need to consolidate the validations for devfile present in dev workspace and odo repository.

The tools' specific validations will remain in their respective repository and only the validations wrt to the devfile spec will be moved to devfile/api.

@elsony elsony added the area/library Common devfile library for interacting with devfiles label Oct 6, 2020
@elsony elsony added the kind/enhancement New feature or request label Oct 8, 2020
@davidfestal
Copy link
Collaborator

Maybe a first step here would be to gather in a document all the Devfile Specification validation rules that are not enforced by the Json schema:

  • Rules about parent or plugin overriding regarding scoping
  • Rules about command groups (only one group can be flagged as default
  • Rules about component or command references (referred-to component or command should exist)
  • etc...

Until now those rules are mainly described in the various initial (often already-closed) GH issues where we discussed the corresponding Devfile 2.0 feature.

As soon as we have those Devfile Spec rules formally listed in a document, we would be able to implement them
possibly in a validation folder of the devfile/api repo ?

@mmulholla
Copy link
Contributor

One problem I have noticed is with the protocol setting for endpoints, for example components.container.endpoints.protocol . By the spec the protocol value should be one of http, https, ws, wss, or tcp. However the schema does not appear to invalidate a setting which is not one of these values, unlike it does for for other one of properties, for example components.container.exposure.

@elsony
Copy link
Contributor

elsony commented Nov 20, 2020

It has been agreed to:

  1. support all 6 protocol settings for the endpoints
  2. update the description of the secure field settings to clarify that the secure protocols, e.g. https or wss instead of the non-secure ones, if the secure field is set to true
  3. In the future, add a warning to the validation if non-secure protocols have been used but the secure field is set to true.

@mmulholla
Copy link
Contributor

See #227

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/library Common devfile library for interacting with devfiles kind/enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants