-
Notifications
You must be signed in to change notification settings - Fork 263
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
Support for Multiple Kubernetes Schemas and CRDs #841
base: main
Are you sure you want to change the base?
Support for Multiple Kubernetes Schemas and CRDs #841
Conversation
Why not allow one to specify, within the settings JSON under the The default configuration would be as it is today, and would simply use the latest released version of the schema. But, with the proposal above, the configuration could look like (note the syntax is using formal JSON syntax to be compatible with coc.nvim, but this could equally apply to VS Code, too, by not using quotes around the property names): {
"yaml.settings": {
"kubernetes": {
"versions": [
"1.22.3",
"1.22.4",
"1.22.5"
],
"files": "*.ya?ml"
}
}
}
|
I am not thrilled with the idea that a segment in the URL changes the meaning of the setting. It is prone to users unintentionally defining Kubernetes schema. I would rather have an intentional setting to manage Kubernetes schemas. Perhaps a combination of what is proposed on #824 and what @fourpastmidnight is proposing. OTOH, I am a bit torn about Kubernetes support. Kubernetes is the only built-in schema that we have on yaml-language-server and this is due to the reasons how I had bootstrapped the project initially. Once we implemented a generic YAML LSP, the built-in Kubernetes support became an outlier. |
I thought it was strange that this lsp server explicitly supported Kubernetes while providing a generic mechanism for other YAML schemas. I wasn't sure if there was any appetite for removing this support, or plans for adding explicit support for other "popular"types. I also think it would be better to remove explicit Kubernetes support as well in light of no plans for explicitly supporting other schemas in lieu of the generic mechanism. I only made the suggestion above based on the current implementation. |
2faf56b
to
c51b12c
Compare
I thought about this as well. I went with this approach because it is a non-breaking API change, e.g. the clients do not have to change anything. I was unable to come up with an intentional non-breaking change. Maybe we can open a new pull request for the intentional kubernetes change in a second step? If we document the magic |
@gorkem @fourpastmidnight Any updates? |
I want to support openshift and different kubernetes version schemas. Therefore, I use this fork until the [upstream pr](redhat-developer/yaml-language-server#841) is merged.
c51b12c
to
5d23a72
Compare
fdf062e
to
88fc144
Compare
I want to support openshift and different kubernetes version schemas. Therefore, I use this fork until the [upstream pr](redhat-developer/yaml-language-server#841) is merged.
4730865
to
ef7c724
Compare
@gorkem @fourpastmidnight @msivasubramaniaan I completely reworked this PR on the basis of #824. What do you think? |
src/requestTypes.ts
Outdated
} | ||
|
||
export namespace KubernetesSchemaURLsNotification { |
Check failure
Code scanning / ESLint
Disallow custom TypeScript modules and namespaces
Hi, what is the status of this pr? |
I'll rebase and fix the code scanning results so that it is ready for merge again. |
596b926
to
f0d5a85
Compare
Ok. I rebased it. @gorkem @fourpastmidnight @msivasubramaniaan Could you run the build again and maybe give some feedback😃. |
Any update @gorkem @fourpastmidnight @msivasubramaniaan? |
any updates? |
@msivasubramaniaan I have seen that you recently merged redhat-developer/vscode-yaml#912 which depends on this pull request. Could you merge this as well? |
Add a new notification to allow users to change the default Kubernetes schema on the fly.
Like this, we can support multiple custom kubernetes associated text documents. E.g. a custom kubernetes version and multiple custom resource definitions (CRDs).
a4a1add
to
0d6bc7c
Compare
@msivasubramaniaan I rebased again because I suspect that the merge of main through the GUI somehow triggered the If the same |
Any updates? |
any updates? |
What does this PR do?
This PR allows to set custom Kubernetes schema versions and Kubernetes Custom Resource Definitions (CRDs).
How Does it Work?
This PR extends #824 by introducing a new yamlSettings.kubernetesSchemaURLs setting and its corresponding notification, e.g:
What issues does this PR fix or reference?
Is it tested? How?