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

Change default registry build style to offline (include all referenced resources in the container at build time) #18242

Closed
nickboldt opened this issue Oct 29, 2020 · 6 comments
Labels
area/ci CI build and releases, PR testing, & whitelabel/productization issues area/devfile-registry area/languages Issues related to Language extensions or plugins integration. area/plugin-registry kind/enhancement A feature request - must adhere to the feature request template.

Comments

@nickboldt
Copy link
Contributor

Is your enhancement related to a problem? Please describe.

Today, starting the Che plugin or devfile registry is fairly quick, since the default build style is "online", in that references to .vsix and icons and project resources are all resolved later.

But this also means that starting a workspace can be slow, as all those plugins have to be downloaded from github, jboss.org, or the open-vsx marketplace.

Starting the workspace also involves checking out code from GH, which can sometimes be slow.

Describe the solution you'd like

Switch registry builds (both devfile and plugin registry) to 'offline' mode by default. This will do two things:

  • devfile registry will, during the build, fetch project sources from the specified repos and branches and include them as zips in the container, guaranteeing that the sources won't "move" after a release (you'll be testing the same project sources as are live in the source project repo). This also enables OOTB airgap support for the sample projects.

  • plugin registry will, during the build, fetch plugins and include them in the container so there's no external dependency on any 3rd party hosting sites, which could unexpectedly be offline. This also enables OOTB airgap support for all the plugins in the registry.

@nickboldt nickboldt added kind/enhancement A feature request - must adhere to the feature request template. area/devfile-registry area/languages Issues related to Language extensions or plugins integration. area/plugin-registry area/productization labels Oct 29, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Oct 29, 2020
@ericwill ericwill removed the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Oct 29, 2020
@nickboldt nickboldt added area/ci CI build and releases, PR testing, & whitelabel/productization issues and removed area/productization labels Apr 6, 2021
@benoitf
Copy link
Contributor

benoitf commented May 4, 2021

Hello @nickboldt and @ericwill
I think we have all the bits to build the plug-in registry embedding all resources. (keeping the surge.sh /github.io without embedding vsix files)
what is preventing to implement it ?

@ericwill
Copy link
Contributor

ericwill commented May 4, 2021

Hello @nickboldt and @ericwill
I think we have all the bits to build the plug-in registry embedding all resources. (keeping the surge.sh /github.io without embedding vsix files)
what is preventing to implement it ?

Apart from time/effort I don't think there are any technical barriers.

@ericwill
Copy link
Contributor

ericwill commented May 4, 2021

I don't think there are any technical barriers.

Of course when I say that I tempt fate...looks like plugins with dependencies still reference some vsix files with HTTP URLs: #19746

@benoitf
Copy link
Contributor

benoitf commented May 4, 2021

Ok I'll take a look at the issue 👍

@nickboldt
Copy link
Contributor Author

As we now include surge.sh / github.io online registries in https://workspaces.openshift.com I'm inclined to close this as won't-do, unless a compelling reason and a contribution from someone who wants/needs it comes along.

Having chatted with Florent on this one, seems like this would not REPLACE the current build/release process for creating online (non-airgapped) registries, but instead supplement it with a SECOND set of registries for offline/airgap usage.

So, after almost 6 months of no effort put into this... close.

If someone wants to put work into this, please reopen it.

@nickboldt
Copy link
Contributor Author

If we decide to do this, it's lower priority than #20549

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ci CI build and releases, PR testing, & whitelabel/productization issues area/devfile-registry area/languages Issues related to Language extensions or plugins integration. area/plugin-registry kind/enhancement A feature request - must adhere to the feature request template.
Projects
None yet
Development

No branches or pull requests

4 participants