Allow specifying an HTTP path for ports defined in .gitpod.yml

[juliusv]

It's great that I can define ports in the .gitpod.yml that are automatically opened in a new browser tab when they become available. For some ports it would be helpful to be able to additionally specify a path to open, since the root path does not always serve something. For example, I have some Prometheus instrumentation examples in https://github.com/promlabs/instrumentation-examples that only serve something on /metrics, not on /.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[juliusv]

Staleness prevention bump :)

[ChevronTango]

Often when exposing ports using gitpod and having services and UIs working in tandem we see CORS issues cropping up. In production these aren't an issue as the API and UI are hosted on the same domain with nginx doing the routing based on path, eg /api/ is routed to a particular api server. In gitpod we can only expose unique domains. This causes CORS issues that the user then has to debug and resolve when the UI domain does not match the API domain.

A way to optionally customize certain ports to instead be exposed at ports-my-gitpod-workspace.gitpod.io/some-custom-path/ to allow more representative testing.

I can see some users wanting to host a ui at / and an API at /api/ as the most common example

Many users take to standing up an nginx server locally, but this can be cumbersome and difficult to manage or keep up to date. It would be much nicer if gitpod was able to do at least the simple path routing on the users behalf.

This is mostly to make dev of complex multi component applications easier and more representative of the production environment they will eventually move into. CORS is very annoying and is frequently the stumbling block our users encounter the most when developing there apps using gitpod.

My suggested implementation is that each port is exposed via two routes. <port>-<domain> as it is currently, and ports-<domain>/<port>/ with the latter having the ability to be changed by the user in config. The prefix is unimportant so long as it is static so its still hosted on the same domain.

[akosyakov]

My suggested implementation is that each port is exposed via two routes. - as it is currently, and ports-// with the latter having the ability to be changed by the user in config. The prefix is unimportant so long as it is static so its still hosted on the same domain.

But it is opposite of the representative in production, no? There are important properties of having different origin like separation of shared state, i.e. cookies, localhost, caches, and so on additionally apps are not necessary respect relative paths. If your application has to deploy everything under subpaths in production why don't you expose it on single <port> in the dev time as well? It seems to be particular issue with devsetup of concrete application.

Also it should be a separated issue.

[ChevronTango]

So the goal is the same, but let's take a step back and consider what would happen if developing on a local device. All your services would be hosted on localhost and you wouldn't have to worry about cors. So it's not representative of a dev who's testing on their local machine. When you move to prod, yes you may have to configure nginx or something else but with all the options for deployments these days there's no guarantee that AWS or other cloud providers wouldn't do that routing for you. Most devs can happily deploy without ever needing to touch ngninx config, or similar.

Disregarding that argument for a second, configuring a proxy like nginx is a pain, and gitpod is already doing the same work with its port proxy, just with less options for the users to configure. I think it's reasonable to ask gitpod to expose a couple extra options to eliminate a sizeable amount of dev that many users are repeatedly having to do in their projects. This is absolutely a convenience request to save devs time and mental strain and get them working with projects quicker and easier.