Unable to run `circleci local execute` from windows machine

[ashthespy]

Running docker on windows:

> docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:21:34 2018
 OS/Arch:           windows/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:29:02 2018
  OS/Arch:          linux/amd64
  Experimental:     true

Attempting to build locally results in: There ins't any extra information when running it with the --verbose flag.

Docker image digest: sha256:3d88cfffd448da07ff8ced22ccdca5adc09ff18e87dc7db9b8af5b8a47647c08
Error: failed to execute docker: not supported by windows

Which would make sense given that "--volume", "/var/run/docker.sock:/var/run/docker.sock" wouldn't work on windows.

After some googlefoo - -v //var/run/docker.sock:/var/run/docker.sock seems to work from windows

But I still have issues getting the docker to build by manually running it for now with:

docker run --interactive --tty --rm ^
    -v //var/run/docker.sock:/var/run/docker.sock ^
    -v %cd%:/root/.circleci ^
    --workdir /%cd%\ ^
      circleci/picard circleci build -c /root/.circleci/config.yml

Error:   error starting container <>: Error response from daemon: invalid mode: /tmp/_circleci_local_build_repo

Error:
Unexpected environment preparation error: Error response from daemon: invalid mode: /tmp/_circleci_local_build_repo

Step failed
Task failed

[marcomorain]

Hi @ashthespy - thanks for creating the issue.

We don't support running builds on Windows at present. I think we should make that error message far more clear, too - "not supported by windows".

That said, there are no fundamental reasons why we don't support Windows right now. It's because of lack of demand, coupled with no-one on the team here using Windows as a dev machine.

I'd be happy to review a PR to get this working.

Marc

[ashthespy]

@marcomorain if you could point me towards the right requirements to get the docker container up and building, I'd be happy to submit a PR with the debugged and working config.

In the current form, the docker run command doesn't work with my windows setup. Especially the -v pwd:pwd mapping. The docker host doesn't know of my current pwd.

I also tired it with:

docker run --interactive --tty --rm ^
    -v //var/run/docker.sock:/var/run/docker.sock ^
    -v %cd%:/root/.circleci ^
      circleci/picard circleci build -c /root/.circleci/config.yml
      REM --workdir /%cd%\ ^

Which hangs at:

====>> Spin up Environment
Build-agent version 0.1.750-336e0196 (2018-09-13T19:48:06+0000)
Starting container <>
  using image <>@sha256:66bbb63816fd3beed4aaf1f31329710db4badaf4487153b023fac9199a8da747

Using build environment variables:
  BASH_ENV=/tmp/.bash_env-localbuild-1539016525
  CI=true
  CIRCLECI=true
  CIRCLE_BRANCH=
  CIRCLE_BUILD_NUM=
  CIRCLE_JOB=build
  CIRCLE_NODE_INDEX=0
  CIRCLE_NODE_TOTAL=1
  CIRCLE_REPOSITORY_URL=
  CIRCLE_SHA1=
  CIRCLE_SHELL_ENV=/tmp/.bash_env-localbuild-1539016525
  CIRCLE_WORKING_DIRECTORY=~/project

====>> Checkout code
  #!/bin/bash -eo pipefail
mkdir -p /root/project && cp -r /tmp/_circleci_local_build_repo/. /root/project
cp: skipping file '/tmp/_circleci_local_build_repo/./port/README', as it was replaced while being copied
cp: cannot access '/tmp/_circleci_local_build_repo/./host_mnt/c/Recovery/Logs': Permission denied
cp: cannot access '/tmp/_circleci_local_build_repo/./host_mnt/c/Documents and Settings': Permission denied
cp: cannot access '/tmp/_circleci_local_build_repo/./host_mnt/c/System Volume Information': Permission denied
cp: cannot stat '/tmp/_circleci_local_build_repo/./host_mnt/c/swapfile.sys': Device or resource busy

It looks like the container is trying to access my C: and thus doesn't succeed?

Setting the current --workdir I get the invalid mode error as above.

[ashthespy]

I still can't get past:

===>> Checkout code
mkdir -p /root/project && cp -r /tmp/_circleci_local_build_repo/. /root/project

I do know I have managed to get the working dir correctly into the docker image. Any leads would be appreciated!

[marcomorain]

If you've gotten as far as ====>> Checkout code, then you have successfully started our docker image (codename picard) and it has started your build container. That's great progress.

I'm not too sure what the checkout step is trying to access on your Window drive, it's likely the current working directory where you project is checked out, and perhaps SSH keys.

@DanToml @dnephin any ideas?

[ashthespy]

Yep, the docker container (circleci/picard) is up and running, and I have managed the --workdir and pdw:pwd mapping also. Now to figure out why cp -r /tmp/_circleci_local_build_repo/. /root/project hangs.

[ashthespy]

So, just gave this a go again - there seems to be some issue with the networking of the container.

====>> Spin up Environment
DEBU[2018-10-11T15:04:18Z] Sending event to OutputProcessor              event="allocationId:\"localbuild-1539270257/436706E1\" type:StepOutput message:\"Build-agent version 0.1.750-336e0196 (2018-09-13T19:48:06+0000)\\n\" timestamp:1539270258825 "
Build-agent version 0.1.750-336e0196 (2018-09-13T19:48:06+0000)
INFO[2018-10-11T15:04:18Z] docker api version is set                     docker_api_version=1.37
INFO[2018-10-11T15:04:18Z] Preparing Docker Executor
DEBU[2018-10-11T15:04:18Z] computed default route before bridge          default_route="default via 172.17.0.1 dev eth0"
INFO[2018-10-11T15:04:18Z] creating ephemeral network for task           network_id=ZZZ_localbuild-1539270257/436706E1
INFO[2018-10-11T15:04:18Z] checking task signals
DEBU[2018-10-11T15:04:18Z] EOF in ListTaskSignals stream
DEBU[2018-10-11T15:04:19Z] computed default route after bridge           default_route="default via 172.25.0.1 dev eth1"
INFO[2018-10-11T15:04:19Z] default route changed, resetting it           after="default via 172.25.0.1 dev eth1" before="default via 172.17.0.1 dev eth0"
WARN[2018-10-11T15:04:19Z] error resetting default routing               error="error setting ip default routing rules: exit status 2" route="default via 172.17.0.1 dev eth0"
DEBU[2018-10-11T15:04:19Z] Sending event to OutputProcessor              event="allocationId:\"localbuild-1539270257/436706E1\" type:StepOutput message:\"Starting container ashthespy/rustcross\\n\" timestamp:1539270259725 "

After this it spins up my container, and then hangs at Checkout code as mentioned previously.

====>> Checkout code
  #!/bin/bash -eo pipefail
mkdir -p /root/project && cp -r /tmp/_circleci_local_build_repo/. /root/project
DEBU[2018-10-11T15:04:28Z] Restarting ListTaskSignals stream
INFO[2018-10-11T15:04:28Z] checking task signals
DEBU[2018-10-11T15:04:28Z] EOF in ListTaskSignals stream
DEBU[2018-10-11T15:04:38Z] Restarting ListTaskSignals stream
INFO[2018-10-11T15:04:38Z] checking task signals
DEBU[2018-10-11T15:04:38Z] EOF in ListTaskSignals stream
DEBU[2018-10-11T15:04:48Z] Restarting ListTaskSignals stream
INFO[2018-10-11T15:04:48Z] checking task signals
DEBU[2018-10-11T15:04:48Z] EOF in ListTaskSignals stream
^CWARN[2018-10-11T15:04:55Z] outer got interruption signal                 signal=interrupt

[dnephin]

I think it should be safe to ignore these errors. They are for features that don't really get used by local execute. We should probably disable them instead of just letting them fail.

For the checkout, I have a proposal here https://github.com/CircleCI-Public/circleci-cli/issues/151#issuecomment-428331116 that I think may resolve the issue for windows as well.

The hanging may be a really slow copy because there are many files in the bind mounted directory. You may be able to confirm by trying to bind mount a directory with only a config file in it.

[ashthespy]

@dnephin You hit the nail on the head. It was trying to add all my Rust build files that were in my .dockerignore normally.

 .\TestBuild.bat
Config file at .circleci/config.yml is valid
====>> Spin up Environment
Build-agent version 0.1.750-336e0196 (2018-09-13T19:48:06+0000)
Starting container circleci/rust
  using image circleci/rust@sha256:3bc151be0f1b0d0b2a10193323bc374726b62a2e1e644e01852fb87f0e676756

Using build environment variables:
  BASH_ENV=/tmp/.bash_env-localbuild-1539291539
  CI=true
  CIRCLECI=true
  CIRCLE_BRANCH=
  CIRCLE_BUILD_NUM=
  CIRCLE_JOB=build
  CIRCLE_NODE_INDEX=0
  CIRCLE_NODE_TOTAL=1
  CIRCLE_REPOSITORY_URL=
  CIRCLE_SHA1=
  CIRCLE_SHELL_ENV=/tmp/.bash_env-localbuild-1539291539
  CIRCLE_WORKING_DIRECTORY=~/project

====>> Checkout code
  #!/bin/bash -eo pipefail
mkdir -p /home/circleci/project && cp -r /tmp/_circleci_local_build_repo/. /home/circleci/project
====>> cargo --version
  #!/bin/bash -eo pipefail
cargo --version
cargo 1.29.0 (524a578d7 2018-08-05)
Success!

Probably OT, but this local build doesn't seem to follow workflows, only runs the first task?

[dnephin]

this local build doesn't seem to follow workflows, only runs the first task?

That is correct, workflows are not supported locally.

[ashthespy]

Okay - the solution is then just the path mapping to get Windows support. i.e Windows (C:\Program Files\meh => /c/Program Files/meh) I don't know how you'd like to implement this in Go. Simple parsing should suffice I'd imagine. A more elaborate approach would be to use cygpath if installed - but I think it's overkill for what we want to achieve - ensure the pwd maps to something reasonable inside the container.

I don't have a Go environment, so it might take me some time to open up a PR :-)

[marcomorain]

cc @KunalJain

[ashthespy]

Oops, this completely slipped of my radar..

[lobanov]

I am also having difficulty here. It would have been very useful to be able to run config locally to reduce cycle time and conserve credits, but unfortunately I cannot do so on a Windows machine. I am getting a different error message to the above, and it seems the code has moved on, as my log looks slightly different.

This is what my command is: docker run -it --rm -v //var/run/docker.sock:/var/run/docker.sock -v <workdir>:/tmp/_circleci_local_build_repo circleci/picard circleci execute -c /tmp/_circleci_local_build_repo/.circleci/config.yml --branch dev --job init

The output looks like the following:

Build-agent version  ()
Docker Engine Version: 19.03.5
Kernel Version: Linux b646ae142e2d 4.19.76-linuxkit #1 SMP Thu Oct 17 19:31:58 UTC 2019 x86_64 Linux
Starting container hashicorp/terraform:light
  image is cached as hashicorp/terraform:light, but refreshing...
light: Pulling from hashicorp/terraform
Digest: sha256:53fb1c0a78c8bb91c4a855c1b352ea7928f6fa65f8080dc7a845e240dd2a9bee
Status: Image is up to date for hashicorp/terraform:light
  using image hashicorp/terraform@sha256:53fb1c0a78c8bb91c4a855c1b352ea7928f6fa65f8080dc7a845e240dd2a9bee
====>> Preparing Environment Variables
Using build environment variables:
  BASH_ENV=/tmp/.bash_env-localbuild-1586786201
  CI=true
  CIRCLECI=true
  CIRCLE_BRANCH=dev
  CIRCLE_BUILD_NUM=
  CIRCLE_JOB=init
  CIRCLE_NODE_INDEX=0
  CIRCLE_NODE_TOTAL=1
  CIRCLE_REPOSITORY_URL=
  CIRCLE_SHA1=
  CIRCLE_SHELL_ENV=/tmp/.bash_env-localbuild-1586786201
  CIRCLE_WORKING_DIRECTORY=~/repo

The redacted variables listed above will be masked in run step output.====>> Checkout code
  #!/bin/sh -eo pipefail
mkdir -p /root/repo && cd /tmp/_circleci_local_build_repo && git ls-files | tar -T - -c | tar -x -C /root/repo && cp -a /tmp/_circleci_local_build_repo/.git /root/repo
fatal: not a git repository (or any parent up to mount point /tmp)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
tar: empty archive
tar: short read
Error:
Exited with code exit status 1

Step failed
Error: runner failed (exited with 101)
Task failed
Error: task failed

The problem seems to be in this line mkdir -p /root/repo && cd /tmp/_circleci_local_build_repo && git ls-files | tar -T - -c | tar -x -C /root/repo && cp -a /tmp/_circleci_local_build_repo/.git /root/repo. However, if I execute the same container with sh -c mkdir -p /root/repo && cd /tmp/_circleci_local_build_repo && git ls-files, I don't get the same git error message and seeing a list of my files instead.

Any ideas?

[TimMensch]

Any chance of CircleCI offering a bounty for the PR?

This is a key feature you're missing -- still nearly half of developers use Windows, and just because you're not using it internally doesn't mean you're not losing customers (like myself) who do a lot of CircleCI development but who feel ignored when an issue as critical as this sits ignored for two years.

The whole "lack of demand" can be explained by the fact that none of your instructions even tell people where to find the circleci image; instead you need to go on a bit of a scavenger hunt to even find it.

And it's a bit harder to motivate to do development that primarily benefits a commercial company.

[phoogenb]

@marcomorain how do you measure demand? In addition to the factor noted by @TimMensch I would note that many Windows developers are probably just giving up as soon as it doesn't work (as I almost did), but would use it if it did work. How do you know how many of those there are?

[talkohavy]

It's been 4 years now...

Please guys, dear maintainers of CircleCI, we really want to be able to run a container locally, otherwise the CLI is useless to us. Most of us (if not all of us) will not leave the comfort of Windows (yes, I said comfort), and if we were forced to choose between moving to another os, or... NOT using the circleci CLI, we would (sadly) choose the latter.

[Walt-LiveRez]

And still we wait ... We have a complex tech stack with older code in .Net Framework (requiring msbuild to compile) and newer stuff in .Net 7, Node, TypeScript, etc. It is problematic for us to only be able to build a portion of our code-base, and not practical to rewrite millions of lines of legacy code.

[sherryysj]

Tried at July 2023, it's still not working on Windows.

[KillariDev]

It's year 2024, still no windows support