search

gitpod-io / gitpod

The developer platform for on-demand cloud development environments to create software faster and more securely.
https://www.gitpod.io
GNU Affero General Public License v3.0
12.98k stars 1.24k forks source link

[ide/dashboard] Assemble IDE preferences based on server-ide-configmap #6601

Closed corneliusludmann closed 2 years ago

corneliusludmann commented 3 years ago

Currently, the preferences page that allows the users to choose an IDE is hardcoded in the dashboard component. However, we actually have nearly everything that needs to assemble this page in the server-ide-configmap to make the available options independent from the dashboard deployments. We could add some extra values here:

https://github.com/gitpod-io/gitpod/blob/335215f565e2912d5d84db3f1502f30ed53d24fd/chart/templates/server-ide-configmap.yaml#L21-L33

e.g.:

and then loop over the available IDE entries to assemble the options. We could also add strings for the infoboxes (like the beta notice with the link to the issue/docs) to this configmap to be able to change them like this as well.

This can be implemented pretty fast and that would allow us, the IDE team, to deploy new IDEs independently of the deployment of the dashboard.

It would be very helpful to have this option pretty soon, e.g. currently we have the GoLand IDE option but the GoLand IDE image is broken since we are waiting for a new upstream version. With the proposed change, the IDE team could easily remove this option for now and add it once we have a new upstream version.

akosyakov commented 3 years ago

@corneliusludmann I was wondering should not we apply approach similar to VS Code Insiders for JetBrains for now, i.e. whatever is merged to main is deployed nightly? Till we have a stable version.

corneliusludmann commented 3 years ago

I was wondering should not we apply approach similar to VS Code Insiders for JetBrains for now, i.e. whatever is merged to main is deployed nightly? Till we have a stable version.

We could think about whether that would be a reduction in work for us (but don't think so at the moment). But this is independent of the proposal in this issue, right?

akosyakov commented 3 years ago

We could think about whether that would be a reduction in work for us (but don't think so at the moment). But this is independent of the proposal in this issue, right?

Yeah, i think this issue is good anyway. I was just wondering of minimal change to enable delivering JetBrains changes to production faster.

loujaybee commented 3 years ago

Just stopping by to say that I think this would fit nicely with our goals of independent deployments and reducing WIP. 🙏

Admittedly, I don't see this being used a lot in the long-term, but I can see how it'd be useful for the short-term as we start to add more IDE's, and might need to remove some.

Note: I've added it to the independent deployment epic that @corneliusludmann is currently working on currently, I think it works well / aligns with that existing goal.

Shall we move to scheduled? @akosyakov / @corneliusludmann ?

corneliusludmann commented 3 years ago

I have not considered in the proposal that dashboard is no longer part of server. That means that we don't have direct access to the server-ide-config in the dashboard. Well, it is pretty easy to expose the needed data via the server protocol. However, when we want to move this config to a dedicated IDE Configuration Service component in the long term I'm unsure if it's worth to add this to the server protocol now.

Pros: Adding this to the server protocol is pretty easy and fast to implement. We can also reuse a lot of code for our IDE Configuration Service later.

Cons: Adding this to the server protocol adds a method to the protocol that we will remove/deprecate pretty soon.

We could also use this use case to start creating a first, small version of an IDE Configuration Service (as a minimum viable change) that just serves the IDE options for the dashboard. If we limit ourselves to implementing only a first iteration with limited functionality, then the effort would be manageable, IMO. But at the end of the day, it's a matter of prioritization. What do you all think about it, @akosyakov @loujaybee?

akosyakov commented 2 years ago

I have not considered in the proposal that dashboard is no longer part of server. That means that we don't have direct access to the server-ide-config in the dashboard. Well, it is pretty easy to expose the needed data via the server protocol. However, when we want to move this config to a dedicated IDE Configuration Service component in the long term I'm unsure if it's worth to add this to the server protocol now.

Oh, I thought IDE Configuration Service which will be internal component which is exposed to the dashboard via the server anyway? cc @csweichel

corneliusludmann commented 2 years ago

/assign

corneliusludmann commented 2 years ago

Address minor preferences improvements during the changes:

akosyakov commented 2 years ago

@corneliusludmann Should we track adding a caddy proxy for IDE team serving IDE icons under this issue as well or create another issue?

corneliusludmann commented 2 years ago

Should we track adding a caddy proxy for IDE team serving IDE icons under this issue as well or create another issue?

→ https://github.com/gitpod-io/gitpod/issues/6955