Enable Che to more easily support latest plugin versions through automation

[l0rd]

Is your enhancement related to a problem? Please describe.

We struggle to manually keep up with the pace of the updates of the vs code extensions. That can have critical consequences for security and UX.

For example if a new version of a vs code extension is released and it patches a critical security vulnerability we should update the relative che-plugin in the plugin registry as soon as possible.

Describe the solution you'd like

Automatically create a PR to update a vs code extension as soon as a new version is released:

• In che-plugin-registry gh repo for vs code extensions referenced in che plugins
• In che-incubator repositories (vscode-git, che-cpptools etc...) for vscode extensions that we patch and build by ourselves
• In theia gh repo for vs code built-in extensions

Describe alternatives you've considered

We should leverage third party tool such as dependabot as much as we can and implement automated jobs by our self when we do not have other options.

Subtasks

• [x] Write a script that checks for new plugins versions #16215
• [x] Run the script daily and provide a report #17014
• [ ] Automatically submit PR (instead of opening issue)
• [x] PR check to validate new/updated vs code extensions #17027
• [x] In plugin-checker fall back to repo/branch package.json when there are no GH releases
• [x] Automatically generate meta.yaml given a vsx repo+branch+dockerfile #17029
• [ ] ~~Build and publish a vsx when there is no corresponding GH release~~
• [ ] Run plugin checker for vscode extensions that we patch (vscode-git, che-cpptools etc...)
• [x] Run plugin checker for vscode built-in extensions (against theia gh repo)
• [ ] ~~Testing a vsx should be easier #15819~~
• [x] Create a che-editors file to store all editors plugin definitions #18214
• [x] migrate vscode-extensions.json to a che-plugins file #18215
• [x] remove v3/plugins folder to use che-plugins/che-editors file #18216
• [x] move sidecars definitions into plugin-registry #18217
• [ ] Ability to run tests of a vscode extension on top of che-theia #18219
• [x] Keep only latest (or next during development) version of a plug-in inside che-plugin-registry #18183
• [ ] Handle dependencies between sidecars in plugin-registry #18363
• [ ] Share build-time resources between sidecars #18364

[ericwill]

Filed sub issue for plugin update checking script: #16215

[gorkem]

* Build and publish a vsx when there is no corresponding GH release

I think we should always build the vsx as part of the automation.

[l0rd]

Added "Testing a vsx should be easier" (#17376) to the subtasks list.

[benoitf]

@ericwill what are the remaining tasks almost all checkboxes are unchecked while I think it's now it should be the opposite

[ericwill]

@ericwill what are the remaining tasks almost all checkboxes are unchecked while I think it's now it should be the opposite

Updated the issue. Also I'm note sure what this means:

• [ ] Automatically submit PR (instead of opening issue)

[benoitf]

I think it was to have new PR when there is new VS Code extension available that is more recent than the one in the plugin-registry (like analyze of the daily report and create PR)

But of course testing the VS Code extension is the must have here

--> Ability to run tests of a vscode extension on top of che-theia #18219

[ericwill]

Understood :+1:

Also I believe Testing a vsx should be easier #15819 is a dupe of Ability to run tests of a vscode extension on top of che-theia #18219

[benoitf]

@ericwill I think it was just a placeholder, 15819 is this epic issue

[gattytto]

could this same procedure be applied to other containers in other repos like image puller operator and its flavors?

[l0rd]

@ericwill with current priorities is roadmap/6-months label accurate or should we set roadmap/3-months?

[ericwill]

@ericwill with current priorities is roadmap/6-months label accurate or should we set roadmap/3-months?

roadmap/6-months is accurate :+1:

[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.

[l0rd]

/remove-lifecycle stale

[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.

[svor]

/remove-lifecycle stale

[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.