Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 61 additions & 25 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,38 +57,74 @@ helm delete --purge che-plugin-registry
docker run -it --rm -p 8080:8080 eclipse/che-plugin-registry
```
### Plugin meta YAML structure:
Here is an overview of all fields that can be present in plugin meta YAML files

|field name in YAML | description | mandatory |
|-------|-------|-------|
| publisher | publisher name | yes |
| name | plugin name | yes |
| version | plugin version | yes |
| deprecate.migrateTo | which plugin should be used instead when plugin is deprecated. Format: publisher/name/version | no |
| deprecate.autoMigrate | if deprecated plugin should be automatically replaced by another plugin specified in deprecate.migrateTo | no |
| type | plugin type | yes|
| displayName | plugin name | yes|
| title| plugin title | yes |
| description| plugin description | yes |
| icon| URL to plugin icon (must be in SVG format) | yes |
| url| an URL to the plugin source | yes |
| publisher| name of plugin publisher | yes |
| repository | URL to repository of the plugin | yes |
| category| plugin category | yes<sup>1</sup> |
| firstPublicationDate | date of publishing the plugin (in ISO 8601) | no<sup>2</sup> |
| latestUpdateDate | date of latest plugin update (in ISO 8601) | no<sup>3</sup> |
| preview | a URL to devfile, to preview this plugin | no |
| tags | a list of tags, related to this plugin | no|
| mediaImage | links for images showcasing the plugin | no |
| mediaVideo | links for video showcasing the plugin| no |
| attributes | a map of special attributes, can be used for instance, imported plugins from VS Code | no |
Here is an overview of all fields that can be present in plugin meta YAML files. This document represents the current `v3` version.

```yaml
apiVersion: # plugin meta.yaml API version -- v2; v1 supported for backwards compatability
publisher: # publisher name; must match [-a-z0-9]+
name: # plugin name; must match [-a-z0-9]+
version: # plugin version; must match [-.a-z0-9]+
type: # plugin type; e.g. "Theia plugin", "Che Editor"
displayName: # name shown in user dashboard
title: # plugin title
description: # short description of plugin's purpose
Copy link
Contributor

Choose a reason for hiding this comment

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

How long, what should it contain?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It should contain a description of what the plugin does; I don't think we have a limit on length.

icon: # link to SVG icon
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this need to be a publicly available url? Does it still have to point to a *.svg?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe it does; would need to confirm elsewhere.

cc: @l0rd

repository: # URL for plugin (e.g. Github repo)
category: # see [1]
firstPublicationDate: # optional; see [2]
latestUpdateDate: # optional; see [3]
deprecate: # optional; section for deprecating plugins in favor of others
autoMigrate: # boolean
migrateTo: # new plugin id
Copy link
Contributor

Choose a reason for hiding this comment

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

Plugin id as in publisher/name/version? What if it's in a different plugin registry?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, new plugin ID. It doesn't make sense to support migrating to another registry IMO since it would be something we don't control. It's intended purpose is to allow a smoother transition between plugin ids within the registry.

@l0rd can confirm.

spec: # spec (used to be che-plugin.yaml)
endpoints: # optional; plugin endpoints -- see https://www.eclipse.org/che/docs/che-6/servers.html for more details
- name:
public: # if true, endpoint is exposed publicly
targetPort:
attributes:
protocol: # protocol used for communicating over endpoint, e.g. 'ws' or 'http'
secure: # use secure version of protocol above; convert 'ws' -> 'wss', 'http' -> 'https'
discoverable: # if false, no k8s service is created for this endpoint
cookiesAuthEnabled: # if true, endpoint is exposed through JWTProxy
type:
Copy link
Contributor

Choose a reason for hiding this comment

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

Possible values?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The meaning of this one is lost to time immemorial. Perhaps @sleshchenko can answer?

path:
Copy link
Contributor

Choose a reason for hiding this comment

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

Path of what?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should be API path but I can't track how it's used across the infrastructure backend.

containers: # optional; sidecar containers for plugin
- image:
name: # name used for sidecar container
memorylimit: # Kubernetes/OpenShift-spec memory limit string (e.g. "512Mi")
env: # list of env vars to set in sidecar
- name:
value:
volumes: # volumes required by plugin
Copy link
Contributor

Choose a reason for hiding this comment

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

Will this create volumes? How does it play with the volumes defined in a workspace config?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No idea.

- mountPath:
name:
ports: # ports exposed by plugin (on the container)
- exposedPort:
commands: # commands available to plugin container
- name:
workingDir:
command: # list of commands + arguments, e.g.:
- rm
- -rf
- /cache/.m2/repository
mountSources: # boolean
workspaceEnv: # optional; env vars for the workspace
- name:
value:
extensions: # optional; required for VS Code/Theia plugins; list of urls to plugin artifacts (.vsix/.theia files) -- examples follow
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 input to the plugin broker, right? How can the user find out which plugin file formats are supported? Shouldn't we mention the restriction on downloading from the vs code marketplace here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There aren't currently many restrictions here; the broker will download whatever you give it.

I hesitate to codify the VS Code marketplace limitation here but can add it if it is important.

- https://github.com/Azure/vscode-kubernetes-tools/releases/download/0.1.17/vscode-kubernetes-tools-0.1.17.vsix # example
- vscode:extension/redhat.vscode-xml # example
- https://github.com/redhat-developer/omnisharp-theia-plugin/releases/download/v0.0.1/omnisharp_theia_plugin.theia # example
```

1 - Category must be equal to one of the following: "Editor", "Debugger", "Formatter", "Language", "Linter", "Snippet", "Theme", "Other"

2 - firstPublicationDate is not required to be present in YAML, as if not present, it will be generated during Plugin Registry dockerimage build

3 - latestUpdateDate is not required to be present in YAML, as it will be generated during Plugin Registry dockerimage build

Note that the `spec` section above comes from the older `che-plugin.yaml` spec. The `endpoints`, `containers`, and `workspaceEnv` are passed back to Che server and are used to define the sidecar that is added to the workspace.

At the moment, some of these fields (that are related to plugin viewer) are validated during the Plugin Registry dockerimage build.

## Get index list of all plugins
Expand Down