-
Notifications
You must be signed in to change notification settings - Fork 138
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
feat: generate json schema for func.yaml #460
Conversation
Signed-off-by: Zbynek Roubalik <zroubali@redhat.com>
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 sure to be a much-appreciated addition by folks editing the func.yaml directly
👍🏻
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lkingland, zroubalik 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 |
@lance @matejvasek what do you think about this? |
@zroubalik I guess I'm not really opposed to this. Of course, I think it's always best to have common/reusable code where possible. But validation is really nice. |
Yeah, I share the same concern. But in this case it makes sense, this makes me wonder, whether I should make to |
I vote for key usually, because |
Signed-off-by: Zbynek Roubalik zroubali@redhat.com
Changes
/kind enhancement
Relates: #336
We can generate json schema for
func.yaml
, the schema could be added to https://www.schemastore.org/json/ -> most of IDEs uses schemastore to enable code completion & validation of certain files for users out of the box:schema.mp4
I wasn't able to add validation to
Envs
andLabels
, because they internally share the same typePairs
, but the validation of values is different for each type: https://github.com/knative-sandbox/kn-plugin-func/blob/818ec572aa52f12a35bb6b022c2e727ce6ebbfd3/config.go#L120-L123A solution would be to re-introduce separate Go types for each property.
Release Note