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

Plugin Broker should support relative paths #14163

Closed
amisevsk opened this issue Aug 8, 2019 · 6 comments
Closed

Plugin Broker should support relative paths #14163

amisevsk opened this issue Aug 8, 2019 · 6 comments
Assignees
Labels
area/plugin-broker kind/enhancement A feature request - must adhere to the feature request template.
Milestone

Comments

@amisevsk
Copy link
Contributor

amisevsk commented Aug 8, 2019

Is your enhancement related to a problem? Please describe.

To support offline plugin brokering, it's necessary for the plugin registry to know its own route. Since extension urls are set at build time, caching extensions locally within the registry (or elsewhere on the cluster) would require updating every meta.yaml's extensions field at startup.

Describe the solution you'd like

The Che plugin broker currently supports downloading extensions via URL or reference to a vscode extension.

To support #14115, the broker should also support relative links. E.g. the reference:

extensions:
  - relative:/path/to/resource.vsix

would resolve to ${CHE_WORKSPACE_PLUGIN__REGISTRY__URL}/path/to/resource.vsix.

This would avoid having to update links at runtime in the offline case.

Describe alternatives you've considered

The main alternative is as suggested in #14115:

Implement a bash script that updates vsix and svg URLs hostnames in meta.yaml files. The new hostname value should be ${CHE_WORKSPACE_PLUGIN__REGISTRY__URL}

Additional context

This shouldn't be very difficult to implement, so even if it's a temporary solution I think it's important.

@amisevsk amisevsk added kind/enhancement A feature request - must adhere to the feature request template. team/osio area/plugin-broker status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Aug 8, 2019
@amisevsk amisevsk self-assigned this Aug 8, 2019
@ibuziuk ibuziuk removed the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Aug 8, 2019
@ibuziuk ibuziuk added this to the 7.1.0 milestone Aug 8, 2019
@nickboldt
Copy link
Contributor

will this change work for icons (.svg files) and theia extension (.theia files) too ? Need that as well as .vsix files for the air gap / offline / plugin-registry-all-in-one container solution planned for CRW 2.0

@amisevsk
Copy link
Contributor Author

amisevsk commented Aug 9, 2019

It should be workable for .theia files without problem but I'm less sure on icons. As far as I can tell icons are ignored everywhere at the moment.

@nickboldt
Copy link
Contributor

if this is a hard target of 7.1.0 I'd raise it to P1 or even blocker. "enhancement" sounds like "when I have time and all my P0, P1, and P2 work is done and my doc updates are done and I still have time left in the sprint" ... or am I reading too much into a label? :D

@amisevsk
Copy link
Contributor Author

@nickboldt Currently the plan is to pull it into our next sprint, it'll probably be the first thing I work on ;)

@ibuziuk
Copy link
Member

ibuziuk commented Aug 28, 2019

@amisevsk can we close this one ?

@amisevsk
Copy link
Contributor Author

Yep, closing as fixed by eclipse-che/che-plugin-broker#70 and #14329

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/plugin-broker kind/enhancement A feature request - must adhere to the feature request template.
Projects
None yet
Development

No branches or pull requests

3 participants