#let's say 10 diff developers are

1 messages · Page 1 of 1 (latest)

onyx kiln
#

Hi Bhaumi!

Sorry, I'm not sure I follow the question, I'll ask a few questions to clarify a bit. How are you planning on using the dev containers?

hidden horizon
#

@high coral , I think I understand your question, so the simple answer yes it is possible, but the details will depend on the requirements of your container.

#

What would help is for you to provide an example of what you are trying to do, and an description of where it fails (or where you begin to have questions

high coral
#

We just want to provide a separate dev container for each PR until PR merges,

Now we want to make this POC with just one machine installed with GitHub self hosted runner and dagger will be installed in the same machine also,

Now when new PR will be created GitHub workflow or pipeline will run in this same machine and that pipeline will create a new dev container with dagger in this same machine

Now after creating a new dev container it will be connected through the remote dev feature in vs code for further development

Like this

hidden horizon
#

We just want to provide a separate dev container for each PR until PR merges,
should be easy
Now after creating a new dev container it will be connected through the remote dev feature in vs code for further development
oh I see. OK, what you describe sounds a lot more like gitpod, where the developer has an ephemeral interactive environment. The environment configuration is static and they only need one instance while they work on their PR

Dagger attempts to solve a different problem. From your perspective I think that dagger would replace the github runner, where a series of automated steps pull prebuilt components from different sources to run a task.

high coral
hidden horizon
high coral
#

who can help to solve this?

onyx kiln
#

Looking at the docs of VS Code (https://code.visualstudio.com/docs/devcontainers/containers) I see that dev containers basically contain a server developed by the vscode team. In that container it seems that the only additional requirements you would need to add is the code of your repository. You could use dagger to start up a container that is based from VS Code's server image, mount the volume of your repository, install the corresponding dependencies your project needs and expose this container as a service. Here is a bit more info on what services are and how to use them: https://docs.dagger.io/757394/use-services/.

The tricky part is plugging the infra together for this to work. Developing the dagger module should be fairly straightforward!

Developing inside a Container using Visual Studio Code Remote Development

Dagger v0.9.0 includes a breaking change for binding service containers. The Container.withServiceBinding API now takes a Service instead of a Container, so you must call Container.asService on its argument. See the section on binding service containers for examples.