Setup the release job for Che-Code

[azatsarynnyy]

Is your task related to a problem? Please describe

Currently, the Che-Code repository doesn't have a release job that could be included in the overall Che release process.

Describe the solution you'd like

Create a GitHub Workflow that would:

• run a script that prepares a release branch;
• build the images;
• publish the built images to the Quay registry.

Describe alternatives you've considered

No response

Additional context

No response

[benoitf]

There used to be branches like 1.62.x, 1.63.x with stable releases of VS Code and the job is cutting release and pushing images etc

https://github.com/che-incubator/che-code/blob/main/.github/workflows/image-publish-stable.yml

I think we should map this way and not cut releases with Che lifecycle as people want mainly to use either insiders version or the latest stable release of VS Code.

[azatsarynnyy]

There used to be branches like 1.62.x, 1.63.x with stable releases of VS Code and the job is cutting release and pushing images etc

https://github.com/che-incubator/che-code/blob/main/.github/workflows/image-publish-stable.yml

I think we should map this way and not cut releases with Che lifecycle as people want mainly to use either insiders version or the latest stable release of VS Code.

I like Florent's idea of providing the Che-Code images based on the VS Code releases.

But let's look at it from both perspectives:

• the community should be able to use the Che-Code image that includes an expected set of the VS Code features/bugfixes
• we should be able to include easily a Che-specific patch into a particular Che release and backport the Che-Code patches to any previous Che release

Che-Code can support both release schedules: VS Code-based and be included in the overall Che release process. So, we can benefit from both approaches.

[nickboldt]

Suggested solution based on chat today w/ Artem:

• add a new make-release.sh script (similar to what's in machine-exec?); this will
  • create a branch every 3 weeks
  • push a commit to trigger an action
• rename image-publish-insiders.yaml to image-publish.yaml and have it handle BOTH main branch -> insiders and next, and add code for handling 7.yy.x -> 7.yy.z releases
• update Che plugin registry builds so that we use the tagged releases in addition to the insiders version of che-code (as we do with theia next and 7.yy.z)
• review DS plugin registry builds to see if there's a followup related task for that forked registry too

[nickboldt]

@svor @azatsarynnyy Do we need to also update https://github.com/eclipse-che/che-plugin-registry/blob/main/che-editors.yaml to point to released che-code images & tags, or just stick with "insiders" ?

[azatsarynnyy]

@nickboldt yes, we need to update the plugin registry as well.
https://github.com/eclipse-che/che-plugin-registry/blob/9d4ee0009c30139b9b67f539b7d720bcc8ccb28f/make-release.sh#L121

So, when the user takes the plugin registry 7.54.0 (for example) they will get the expected version of Che-Code - 7.54.0.

[benoitf]

I still don't know why the lifecycle of Che should be used in CheCode

I expect as a user to have a VS Code v1.71.0, not a VS Code 7.54.0

[azatsarynnyy]

I still don't know why the lifecycle of Che should be used in CheCode

I expect as a user to have a VS Code v1.71.0, not a VS Code 7.54.0

@benoitf with the VS Code releases-based versioning it will be much harder to track the mapping of Che versions to Che-Code versions. For example, when we need to backport the patches between different Che versions.

[nickboldt]

initial PR che-incubator/che-code#103

[nickboldt]

closed too early by automation. Remaining work:
Suggested solution based on chat today w/ Artem:

• add a new make-release.sh script (similar to what's in machine-exec?); this will
  • create a branch every 3 weeks
  • push a commit to trigger an action
• rename image-publish-insiders.yaml to image-publish.yaml and have it handle BOTH main branch -> insiders and next, and add code for handling 7.yy.x -> 7.yy.z releases
• update Che plugin registry builds so that we use the tagged releases in addition to the insiders version of che-code (as we do with theia next and 7.yy.z)
• review DS plugin registry builds to see if there's a followup related task for that forked registry too

[l0rd]

@mkuznyetsov @nickboldt can we close this issue? I am asking to decide if we should include it in 7.54 release notes or not.

[nickboldt]

As discussed today, "review DS plugin registry builds to see if there's a followup related task for that forked registry too" means:

• https://github.com/redhat-developer/devspaces/blob/devspaces-3-rhel-8/dependencies/job-config.json#L29-L33 --> move 3.3 to use 7.54.x branch

See also:

• https://github.com/redhat-developer/devspaces/blob/devspaces-3-rhel-8/product/updateVersionAndRegistryTags.sh#L184-L185
• https://github.com/redhat-developer/devspaces/blob/devspaces-3-rhel-8/product/updateVersionAndRegistryTags.sh#L229-L230
  where we need some sort of "if 3.2 use devspaces-3.2-rhel-8 branch; else 7.yy.x (or main)" logic

So... can't close it until it's actually complete. That's why there's a checklist! :/

[nickboldt]

I see job-config.json was manually updated redhat-developer/devspaces@d5efb31 via redhat-developer/devspaces#816 but the script has not been fixed so that it will do the correct mapping for 3.3+.

https://github.com/redhat-developer/devspaces/blob/devspaces-3-rhel-8/product/updateVersionAndRegistryTags.sh#L184-L185
https://github.com/redhat-developer/devspaces/blob/devspaces-3-rhel-8/product/updateVersionAndRegistryTags.sh#L229-L230

Issue remains open. @mkuznyetsov please LMK if you have a PR for this fix.

[nickboldt]

See PR redhat-developer/devspaces#835 which manually updated job-config.json to achieve what I asked @mkuznyetsov to do 20 days ago via script.

[nickboldt]

Updated the script here: redhat-developer/devspaces@657f2f5 and verified it works here: redhat-developer/devspaces@f98a171 so it's ready for when we branch for 3.3/3.4