Post Create Command fails when cloning docker compose repo in container volume

[daniellaera]

Once cloned repo in the container volume, the post create command "postCreateCommand": "yarn install" or "postCreateCommand": "npm install"

throws an error saying that impossible to find yarn.lock/package.json so impossible to install dependencies

• VSCode Version:
  latest

Steps to Reproduce:

1. clone repository in container volume
2. // Use 'postCreateCommand' to run commands after the container is created.
   "postCreateCommand": "yarn install"
   fails

example with npm

[JeremyGrieshop]

I think the latest extension version broke the current working directory when the post Commands run.

My container also complains about not being able to find scripts that I set from postCreateCommand, postAttachCommand and postStartCommand properties. And it only started happening after this last update.

[Chuxel]

Moving to vscode-remote-relase. Yeah my first question is what is in the repository.

Given your output, I assume you're doing this in Remote - Containers correct (not Codespaces)?

//cc @chrmarti

[JeremyGrieshop]

If you're asking me, I'm indeed using the Remote Containers (not Codespaces). I had originally used these instructions for my .devcontainer configuration a long time ago: https://code.visualstudio.com/remote/advancedcontainers/improve-performance#_use-a-named-volume-for-your-entire-source-tree

I used the "Clone repository into named volume". In previous versions of the extension, the post commands would operate from the current working directory of /workspaces/{repo}, which was correct. Now, it's /workspace, so it can no longer find the root of the source tree.

[daniellaera]

same scenario as @JeremyGrieshop

[ijaouani]

I have the same issue.

My devcontainer is based on https://github.com/microsoft/vscode-dev-containers/tree/v0.209.6/containers/javascript-node-postgres.

If I open the repo using "Open a folder in Container" it works but not when using "Clone Reposository in container volume" since recent changes on vscode or extension.

I have replace my postCreateCommand with :

"postCreateCommand": "pwd && yarn install"

And the path is /workspace instead of /workspaces.

I am really confuse why I have both of them.

[Chuxel]

@ijaouani The path should be /workspace in this case since that is how the definition is set up (see here). Is postCreateCommand trying to from /workspaces/<blah> ?

@JeremyGrieshop @daniellaera Do your devcontainer.json files have something set in workspaceFolder? Does this match where the command is running? If so, is the source code not in this location?

[ijaouani]

Thanks to @JeremyGrieshop I have found a workaround : Downgrade the version to 0.224.3 here :

[JeremyGrieshop]

@ijaouani The path should be /workspace in this case since that is how the definition is set up (see here). Is postCreateCommand trying to from /workspaces/<blah> ?

@JeremyGrieshop @daniellaera Do your devcontainer.json files have something set in workspaceFolder? Does this match where the command is running? If so, is the source code not in this location?

Yep, I used the same sample from https://code.visualstudio.com/remote/advancedcontainers/improve-performance#_use-a-named-volume-for-your-entire-source-tree:

"workspaceFolder": "/workspace",

And this is how it has been working for a long, long time. The /workspace has always transformed into /workspaces/${repo} somewhere along the way, and I never bothered to question it. I guess the scenario is of having a single, isolated workspace at /workspace vs multiple workspaces at /workspaces. This process has always confused me, too.

[Chuxel]

@chrmarti Is this as a result of a bug fix that caused workspaceFolder to be respected where it originally was not?

[ijaouani]

@ijaouani The path should be /workspace in this case since that is how the definition is set up (see here). Is postCreateCommand trying to from /workspaces/<blah> ?

@JeremyGrieshop @daniellaera Do your devcontainer.json files have something set in workspaceFolder? Does this match where the command is running? If so, is the source code not in this location?

It's exactly that I don't understand and really confusing to me :

• In both devcontainer.json and docker-compose file I am using the default template value:

  "name": "Node.js & PostgreSQL",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace",

    volumes:
      - ..:/workspace:cached

• When opening this with a local git repo (Open a folder in Container) the source code is mount in the container into /workspace folder.
• When opening this with a container volume (Clone Reposository in container volume) the source code is mount in the container into /workspaces folder. The content of the /workspace remain even if I delete everything on docker (docker system prune -a --volumes). I have no idea that is the target of /workspace in this case

[daniellaera]

my "workspaceFolder": "/workspace",
is well configured too, like @ijaouani and @JeremyGrieshop I've always worked like so since long time, no issue until today

[Chuxel]

Ahh got it workspace**s** while the config says workspace (w/o s) - that does sound like a bug.

[daniellaera]

yes, is maybe the reason

[Chuxel]

@chrmarti SImple repro: Open this in a container volume: https://github.com/Chuxel/empty/tree/python-postgres

On macOS you have to allow sharing /workspaces because of #5388.

Regardless, the npm install will fail - you can see its /workspace as the location its trying to use but the source code is not mounted there. So postCreateCommand obeys workspaceFolder but the source code mounting does not.

[ijaouani]

Just to provide more analysis on the subject :

Using docker inspect we have the following :

    "Mounts": [
        {
            "Type": "bind",
            "Source": "/workspaces/platform",
            "Destination": "/workspace",
            "Mode": "cached",
            "RW": true,
            "Propagation": "rprivate"
        },
        {
            "Type": "volume",
            "Name": "platform-145ecb8f78618e8a898f4d80473b5096",
            "Source": "/var/lib/docker/volumes/platform-145ecb8f78618e8a898f4d80473b5096/_data",
            "Destination": "/workspaces",
            "Driver": "local",
            "Mode": "z",
            "RW": true,
            "Propagation": ""
        },
        {
            "Type": "volume",
            "Name": "vscode",
            "Source": "/var/lib/docker/volumes/vscode/_data",
            "Destination": "/vscode",
            "Driver": "local",
            "Mode": "z",
            "RW": true,
            "Propagation": ""
        }
    ],

The second volume is the git in docker volume for the repo. The last one is used certainly by vscode nothing interesting here but the first one makes no sense for me from docker perspective.

The source of the bind is normally a local path and on windows /workspaces/platform does not exist at all. I am really curious how this bind is working and that it's currently targeting.

And also :

From the devcontainer build log we have the following :

[43729 ms] Start: Run in container: cat /workspaces/platform/.devcontainer/devcontainer.json 2>/dev/null
[43734 ms] Start: Run in container: cat /workspaces/platform/.devcontainer/devcontainer.json 2>/dev/null
[43738 ms] The options 'workspaceMount' or 'workspaceFolder' are ignored when cloning a repository into a volume.
[45337 ms] Start: Run in container: docker-compose version --short
[47535 ms] Start: Run: docker ps -q -a --filter label=com.docker.compose.project=platform_devcontainer --filter label=com.docker.compose.service=app

[JeremyGrieshop]

Seems to me that it's sort like creating a symlink at the docker mount level by re-mapping /workspace over top of the appropriate /workspaces/{repo}

[chrmarti]

Fixed in Remote-Containers v0.231.2 and v0.232.2-pre-release.

[ijaouani]

@chrmarti can you just put the link of the commit. Curious about it.