Gitpod: REQUEST: Allow end-users to chose their preferred dockerimage

Created on 24 Feb 2020  路  15Comments  路  Source: gitpod-io/gitpod

My repository supports running gitpod in ubuntu and debian docker containers where there is no way for the end-user to chose which one is preferred.

Requesting to add a method to define multiple dockerimages for end-user to choose from.

enhancement wontfix

Most helpful comment

@jankeromnes - Your point about what Gitpod was designed for is well-taken. Still, I think there's room for (1) allowing more flexibility in the distro that a user bases his/her workspace on, and (2) making a parameter in the workspace URI accessible to the workspace build process (e.g., to setup a workspace in a specific configuration.

Of course, adding the above together could give the functionality I originally requested :-)

All 15 comments

@ronys proposed quoting: "?param=value that I can add to the creation URL. For example: gitpod.io/#https://githob.com/pwsafe/pwsafe?distro=fedora32" on
https://github.com/pwsafe/pwsafe/pull/662#issuecomment-636505833

Which to me seems as a good idea.

@nisarhassan12 Care to help me implement this in gitpod? ^-^

I would think that we could detect a gitpod/dist directory with foo.dockerfiles that can be used in the ?param=foo

kreyren doesn't have an access to the relevant source code

Thanks. I would like to help but I also don't have access to the relevant source code.

JANX! @jankeromnes

AFAIK this is the first request of such a feature. Why would you want to choose between different linux in the same project?

As a workaround you could have a separate branch with that config.

@svenefftinge second! :p

Because there are people like me who hate ubuntu (and for good reasons!) and prefer to use debian or other distribution (exherbo ideally) for their development assuming that downstream service quality is a concern too and for debugging of the source code assuming that dependency could break the runtime which is hell to do on apt-based distros and source-based are mostly designed to handle this without the need to make changes to the base system running on the same system without namespaces and VM.

EDIT: Wording

As a workaround you could have a separate branch with that config.

that's pita to maintain and creates a spam in the repo branches

Btw. i've made a contrib to gitpod-layers adapted to support requested Linux mint and fedora, will make a merge request once we can implement this~

AFAIK this is the first request of such a feature. Why would you want to choose between different linux in the same project?

My use case is that as a open source project developer, I'd like to build, test and package my software (PasswordSafe) on and for popular distributions. Currently I'm doing this (mostly) manually using VMs on my home PC. Seems to me that this is a good candidate for moving to the cloud, with Gitpod in particular "almost there" in terms of the functionality I need.

My use case is that as a open source project developer, I'd like to build, test and package my software (PasswordSafe) on and for popular distributions

FWIW this would require pushing changes and then reopening gitpod to test them on a different distribution which in my mind is pain to do.. AFAIK the general practice for this is to use Docker or Vagrant so that you can run the within the terminal i.e:

sudo docker run debian sh -c 'apt-get update -q && apt-get install -qy busybox git lsb-release && git clone https://github.com/Kreyren/forkless-pwsafe.git && busybox sh forkless-pwsafe/Misc/name-me.sh && make -C forkless-pwsafe build'

Which is what i was using in https://github.com/pwsafe/pwsafe/pull/663, but you can't use docker on gitpod due to the https://github.com/gitpod-io/gitpod/issues/52

If you would like to have this functionality i can write a wrapper for you that is using a https://sr.ht which in theory should have the same or similar functionality, but i need to do more research in that.


This is issue is for user preference for example gitpod users who doesn't want to use Ubuntu in their workspace without the need to do https://github.com/gitpod-io/gitpod/issues/1263#issuecomment-636516442 on a repository which is configured to use gitpod/* dockerimage which is most of them.

Gitpod makes it easy to set up your preferred dev environment per project.

It was designed to support one common environment per repository (that way everyone in the team is using the same consistent image / tools / workflows / etc), i.e. you "normalize" the dev setup, as opposed to having everyone in your team use different tools and report different bugs and not having a common base thus making collaboration and quality harder to achieve.

I don't see the point of having a dedicated feature in Gitpod that allows you to switch between multiple different setups in a single repository (kind of defeats the point of a unified shared environment).

However, you already have these options today:

  • If you hate Ubuntu, you can use Debian for your repository's dev environment (or Alpine, or Amazon Linux)

  • If you really want the ability to switch between different base images in Gitpod for the same source code, there is no need to build this as a dedicated feature: you can simply create two repositories, with two different Dockerfiles (and if you want to use exactly the same code base, you can include the main repository as a Git sub-module into the second repository).

I'm inclined to vote "won't fix", because this is a rare special use case, which is already achievable today without changes to Gitpod.

Please let me know if I've misunderstood the request, or if you disagree with some of my points. I'm happy to discuss this further.

It was designed to support one common environment per repository (that way everyone in the team is using the same consistent image / tools / workflows / etc), i.e. you "normalize" the dev setup, as opposed to having everyone in your team use different tools and report different bugs and not having a common base thus making collaboration and quality harder to achieve.

Seems as bad implementation and restriction to me~

I don't see the point of having a dedicated feature in Gitpod that allows you to switch between multiple different setups in a single repository (kind of defeats the point of a unified shared environment).

That way you can comfort everyone in the team who prefers different linux distribution (or different kernels ideally) while being able to use various distro-specific features alike Exherbo allows end-users to install packages as non-root and test dependency issues and apply patches easily without the need for makefile handling compared to limited apt that is just stupid wrapper for cp command in my opinion~

If you really want the ability to switch between different base images in Gitpod for the same source code, there is no need to build this as a dedicated feature: you can simply create two repositories, with two different Dockerfiles (and if you want to use exactly the same code base, you can include the main repository as a Git sub-module into the second repository).

How is this sane to do on any repository! Can you even imagine the stress this puts on upstream assuming that you would have to have X amount of repositories all with submodules that poins to the target repo when there could only be a switch in gitpod.io/settings or toggle to show a GUI for repositories that supports this >.<

Note that none is asking you to maintain all these images (aldo it would be very simple to do using my refactor..) meaning allowing github repositories to use gitpod/dist directory to show the GUI to chose from a preferred dockerimage else falling in current behavior~

Note that me and @nisarhassan12 are happy to implement this ^-^

Unless there is something internal that is causing a heart attack in typefox that i am not aware of that would make this implementation a bad idea O.o

@jankeromnes - Your point about what Gitpod was designed for is well-taken. Still, I think there's room for (1) allowing more flexibility in the distro that a user bases his/her workspace on, and (2) making a parameter in the workspace URI accessible to the workspace build process (e.g., to setup a workspace in a specific configuration.

Of course, adding the above together could give the functionality I originally requested :-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tekumara picture tekumara  路  3Comments

Kreyren picture Kreyren  路  3Comments

ColbyWTaylor picture ColbyWTaylor  路  3Comments

akosyakov picture akosyakov  路  3Comments

kuniss picture kuniss  路  3Comments