amisevsk
commented
5 years ago After discussion in standup today, and discussion with @nickboldt prior, I'd like to propose an alternate solution for this issue:
Difficulties with the current solution
The required steps to implementing cached project zip files would be:
- Download zips for all projects listed in devfiles (not difficult)
- Rewrite all project URLs in a way that makes the cached zips available to workspaces (difficult)
- This is hard to do. On the plugin registry, caching vsix files is relatively simple as the URL translation logic is stored in the plugin broker; we can specify relative paths and have them resolved at runtime. With the devfile registry, we would have to build these URLs at runtime, since the route to the registry is unknown
- This also requires modifying the deploy process in all cases, as the deployer for Che would need to get the registry URL and add it as an env var for the deployment.
- Ensure the rest of the flow can handle pulling in a zip, unzipping it, and storing it in the right place as a git project (maybe already supported, I haven't investigated much).
Assumptions
- Users running Che in an airgapped scenario do not highly value running our sample projects beyond just testing a few things out / demoing
- This is especially true as many of our sample projects link to community-owned projects that we currently have no control or stake in (e.g. the realworld samples, which often don't even come with licenses)
- It's still important to serve sample devfiles that can start basic application stacks, as users can use these as a template for adding their own projects
Proposal
Instead of building a registry that has project zips cached locally (which then theia pulls and unzips to start the workspace), instead the "offline" build of the devfile registry removes sample projects from workspaces. This allows users to quickly start up workspaces with the tooling they expect, and provides a base into which they can add a project that is relevant to them. Once someone is up and running with Che, with their own project-specific devfiles ready, the devfiles in the registry become less and less useful.
@l0rd @nickboldt WDYT?
nickboldt
l0rd
benoitf
ibuziuk
Is your enhancement related to a problem?
If Che is deployed on a cluster that doesn't have access to github (because behind a firewall or offline) the sample stacks won't work. For that reason we need to build a devfile registry image that contains the samples source code.
Describe the solution you'd like
The projects could be cloned, packaged as zipfiles files and copied in the images at build time. The devfiles should be edited to reference the zipfiles instead of the github repositories. That's similar to what is done for the vsix extensions and the plugin registry.