feat: Add configuration for OpenShift deployment and Eclipse Che development

[svor]

This PR introduces a .devfile.yaml that sets up a complete development environment in Eclipse Che for developing, testing, and running OpenVSX.

Watch the screencast to see how it works:
Run_in_Che.webm

The PR also includes a deployment configuration for OpenShift, enabling the deployment and operation of a custom OpenVSX registry on OpenShift. Additionally, it provides the capability to patch Eclipse Che, allowing it to seamlessly integrate and use this custom registry.

Watch the screencast to see how it works:
Deploy_on_OpenShift.webm

A new badge has been added to the main README.md, providing a direct link to open the Eclipse Che developer environment for working with OpenVSX:

Related issue: eclipse-che/che#23148

[amvanbaren]

@svor Who's going to maintain the openshift directory?

[ibuziuk]

@amvanbaren Red Hat is going to support the openshift directory. We can contribute the CODEOWNERS file if needed with the specific list of developers

[amvanbaren]

@ibuziuk I think it might be better to move the openshift directory to a separate repo. I'm happy to add a link to it in the wiki: https://github.com/eclipse/openvsx/wiki/Deploying-Open-VSX

[ibuziuk]

@amvanbaren could you clarify why not to have it in the upstream repo? There are already other product config files / setup for cloud providers available in repository and README.

[amvanbaren]

@ibuziuk Yes, those configurations are directly related to running the Open VSX registry (Azure blob storage, Google cloud storage, Github authentication). While running Open VSX on OpenShift is one of numerous ways how the infrastructure can be set up.

[ibuziuk]

@amvanbaren well, there are also product-specific configuration files in place for development - https://github.com/eclipse/openvsx?tab=readme-ov-file#development

[amvanbaren]

@ibuziuk The proposed changes in README.md and development.md are ok, but I think it might be better to move the openshift directory to the Eclipse Che repo or a new repo.

[deboer-tim]

This does seem to contradict Eclipse vendor-neutral governance though? Why one product included and not another?
@kineticsquid

[kineticsquid]

@deboer-tim @ibuziuk I'm experimenting with your PR. The Dev spaces link, https://docs.redhat.com/en/documentation/red_hat_openshift_dev_spaces, in the readme takes me to a specific devspace release. But it's not clear how I can start a Dev space. Clicking 'My Trials', I see a 'Developer Sandbox' link, but nothing for Dev spaces.

[ibuziuk]

@kineticsquid if you navigate to https://workspaces.openshift.com/ and create the Developer Sandbox account you should be able to start a CDE based on the URL from the readme badge https://workspaces.openshift.com#https://github.com/eclipse/openvsx

[kineticsquid]

OK, I got my devspaces trial working. I forked @svor's repo and tried the OpenShift link. Got my development environment up and running fine. But, I didn't see a chance to pick a branch and ended up with master. I then made the branch with the changes the default branch and tried again. That worked and I ended up with a development environment with the changes. But, I didn't see an actual running instance of the deployed code. Is that by design, or did I do something wrong?

[svor]

@kineticsquid

But, I didn't see a chance to pick a branch and ended up with master. I then made the branch with the changes the default branch and tried again.

This is expected because the default branch is set to master on https://workspaces.openshift.com#https://github.com/eclipse/openvsx, and changes from the current PR aren’t available there until it is merged.

But, I didn't see an actual running instance of the deployed code. Is that by design, or did I do something wrong?

Initially, the OpenVSX instance doesn’t run in the workspace. To start the OpenVSX instance in the workspace, please follow these instructions: https://github.com/eclipse/openvsx/blob/e85204be985df870e780473f2fd66aab43238390/doc/development.md#using-red-hat-openshift-dev-spaces

The second part of the commands in devfile.yaml (2.1 - 2.6) is designed to build and deploy OpenVSX to an OpenShift cluster. However, these commands (described here) won’t work properly on the https://workspaces.openshift.com/ instance, as they require OpenShift cluster admin privileges. To execute these commands, you need to have admin access to your own OpenShift cluster.

[kineticsquid]

@svor Thanks for the explanation. Re:

The second part of the commands in devfile.yaml (2.1 - 2.6) is designed to build and deploy OpenVSX to an OpenShift cluster. However, these commands (described here) won’t work properly on the https://workspaces.openshift.com/ instance, as they require OpenShift cluster admin privileges. To execute these commands, you need to have admin access to your own OpenShift cluster.

Is there a way to do this free of charge, or to have admin privileges, one needs a paid plan?

[kineticsquid]

One other question I think for our committers. This PR includes a script that publishes extensions to an instance deployed on an OpenShift Cluster. It seems this script should either be general for any deployment or, if it needs to be specific to OpenShift, be located in the OpenShift folder.

[svor]

One other question I think for our committers. This PR includes a script that publishes extensions to an instance deployed on an OpenShift Cluster. It seems this script should either be general for any deployment or, if it needs to be specific to OpenShift, be located in the OpenShift folder.

@kineticsquid If I get your question correctly, this script is OpenShift specific and is used only for publishing extensions to the registry deployed on OS. It's already located under openshift folder: openshift/scripts/publish_extensions.sh

[kineticsquid]

@svor Thanks, you do understand my question correctly and you're right, sorry, I missed that.

[waynebeaton]

Please make sure that the contribution has the usual copyright and licence headers.

Other than that, I see nothing controversial here.