Support for devcontainer images that already have the workspace git repo baked in

[marklarr-gfm]

Is your feature request related to a problem?
No

Which solution do you suggest?
A --no-source or maybe a --create-workspace=false devpod customization that will indicate to devpod that the git workspace is being provided via the devcontainer image, and devpod does not need to do any work to create a workspace in the devcontainer.

Which alternative solutions exist?
Right now, we are working around this by having a .devcontainer.json that looks like this:

{
  "name": "foo devcontainer",
  "image": "foo-image-already-has-workspace-in-it",
  "remoteUser": "user",
  "containerUser": "user",
  "workspaceFolder": "/home/foo-workspace"

   // Clobber over the foo-workspace that devpod creates with our foo-workspace-baked-into-image
  "postCreateCommand": "rm -rf /home/foo-workspace/* && cp -RT /home/foo-workspace-baked-into-image/ /home/foo-workspace/ && rm -rf /home/foo-workspace-baked-into-image"
}

Additional context
More info for our use case — our build tool, gradle, combined with our monorepo setup, requires that a developer waits 5-10 minutes for gradle to build after a fresh repo clone. To provide a faster setup for developers, we've cloned our monorepo in our devcontainer image Dockerfile, and then ran gradle on that inside our Dockerfile as well. The result is that our developers' newly created devpods will already have gradle built for them out-of-the-box.

[pascalbreuninger]

Hi @marklarr-gfm, could prebuilds solve your problem as well?

[marklarr-gfm]

Hey @pascalbreuninger 😄 we had originally tried using prebuilds, but due to our large docker context (which contains all our Kotlin monorepo codebase) + the way the PrebuildHash is based on the contents of the docker context, this was resulting in users of our .devcontainer.json to never get the benefit of a prebuilt image. The docker context is constantly changing (since our Kotlin code is constantly changing), and so the PrebuildHash is constantly changing.

I do think prebuilds could be a good solution for us, but for our use case, we would need some tighter control over how the PrebuildHash is being generated. I think it would be sufficient for our use case if we specifically had the ability to opt-out of having the PrebuildHash be based on the entire docker context, and instead, a subset of the docker context (eg, only the bash scripts we use inside our Dockerfile)

FWIW we would want to make new prebuilds over time as our Kotlin code changes (to get a more fresh warm-up of gradle+intellij for our developers), but we don't necessarily need or even want to do it on every single commit to the Kotlin code. It would be sufficient for us to instead, for example, have a weekly scheduled GH Action that forces a rebuild even if the PrebuildHash has not changed (which, as far as I remember, devpod already supports)

So TL;DR, I think prebuild hashes would be a good solution for us, we just need a way to customize the PrebuildHash so it is not as volatile, given our use case with a large Docker context (most of which is just used to "warm up" and doesn't need to be 100% up-to-date always)

(Note: There is also the matter of DevPod prebuilding only supporting local docker daemon, and not Kaniko. This is not a hard blocker for us, but it does limit the number of places we will be able to build these images vs when we do it with Kaniko in our k8s cluster.)

[pascalbreuninger]

Ah I see, thanks for the explanation! We'll discuss this and come up with a solution

[tulequ]

I have similar problem: because our source is big, I don't want every user clone then upload to remote k8s So the code should mount on NFS, then on pod start, we can run git clone --reference ... or rsync+fetch

I intent to use this way

devpod up <image>

But there are no way to add option like "overrideCommand": false or postCreateCommand, so we can't exec git clone --reference or copy

So I propose a solution: add --local-devcontainer <path> to use a local .devcontainer.json (without clone a repository)

[aacebedo]

I am also facing this issue and noticed it is linked to the use of a .devcontainer.json file or a .devcontainer folder as I think the context is not the same on those two cases.

To me in the case it uses the .devcontainer.json, it shall not take the entire project directory as context as it defeat the purpose of dev container. If project files unrelated to the container definition change, it shall not rebuild the container as it will annihilate the usefulness of the prebuilt feature.

I think the container hash in the case it is started with a .devcontainer.json, shall only use the file and the .devpod-internal dir and the location where it put downloaded features as hashing elements.

@pascalbreuninger what do you think?