Move che-theia plugins to dedicate repository and optimize build flow of che-theia image

[vzhukovs]

Is your enhancement related to a problem? Please describe.

Want to share with you some notes about the flow, how we build che-theia image. Each time, when developer builds the image, all the plugins, located in che-theia/plugins include into this build flow. Plugins build flow takes around 1m50s - 2m30s average. Which is quite a lot, especially when there isn't any changes made there. Sometimes we just wasting these two minutes, doing this recurring action. As far as i am concerned, plugins don't change so often, and I think that they can be stored in GitHub, like it has been done for VSCode built-in extensions: see Assets.

Describe the solution you'd like

1. Create dedicate repository, where che-theia plugins will be located instead of che-theia/plugins.
2. Make it possible to release che-theia plugins independently from che-theia (like it done with VSCode built-in extensions: assets)
3. Modify che:theia init command, which will modify theia/package.json to include into theiaPlugins section urls for our che-theia plugins.
4. Modify foreach_yarn to extract pre-built che-theia plugin instead of build it from sources.

For cases, when developer need to perform changes in che-theia plugin and test it, plugin can be cloned into che-theia/plugin or somewhere else and specify build script to consume the plugin from this directory instead of downloaded one.

Describe alternatives you've considered

N/A

Additional context

N/A

@benoitf, @l0rd, @azatsarynnyy, @vinokurig, @vitaliy-guliy, wdyt?

[benoitf]

For notice, there were several repositories before and it was all merged into a single/monorepository https://github.com/eclipse/che/issues/12306

I think main argument was 'simplicity'

• you could both change/update a plug-in and @eclipse-che changes in a single PR. Else you'll to provide PR across different repositories. So for review/lifecycle it was easier.

[tsmaeder]

I think it would make more sense to fix the build process so that we can rebuild individual modules reliably: then we could just rebuild the modules we need (aka the stuff we're working on and che-theia itself) and be done. In my experience, reliability (aka, my build is broken, I need to set up a new workspace) has used up more time than rebuilding. If multiple repositories can help with that, I'm all for it, otherwise, no!

[tsmaeder]

(But glad we're investing in self-hosting)

[benoitf]

@vzhukovskii as discussed on chat previously:

I think we need to tackle the problem but it might not mean that splitting repositories would solve all issues. For example being able to develop/change/test a default plug-in and a single PR to make the change is lot easier with single repository. That said, it doesn't mean that we can add flags/options to bypass some elements of the build that might not be interesting for some use-cases because it seems it was the original issue you reported.

You could for example have parameters to

• use latest generator instead of rebuilding it
• use latest plug-ins instead of rebuilding them
• disabling again linters
• etc

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[ericwill]

Since nothing was done here I'll assume it's still valid, so reopening it.