I wanted to quickly post some notes from the gitter channel (so that they don’t get lost)
Initially I thought this might be a network issue (based on the error message) but the error message itself seems like a symptom of a different issue. That issue is that builds are immediately failing because the working dir is not being created automatically on some clusters (more how I came to this conclusion below). The result is the following error:
chdir to cwd ("/drone/src") set in config.json failed: no such file or directory
So first of all, I want to note that this does not impact all Drone users or clusters. I am testing with Digital Ocean’s hosted Kubernetes offering, and with Kubernetes on Docker for mac, and I am not able to reproduce the issue. This leads me to believe it may be a vendor-specific problem (so be sure to post details about your cluster, including version and hosting provider).
Initially I thought perhaps it was a permission issue and that host machine volumes were not being mounted. One of the community members in the gitter channel, who is getting the same error described in this thread, was able to confirm that volumes are in fact being created and mounted:
@brandom: I took a look and my nodes have successfully created folders under /tmp/drone on the host, like
The main difference we found was that in my installation the
src directory is automatically created in the volume (below). For individuals getting errors, the
src directory was not automatically being created.
$ ls -la /tmp/drone/b7b6svgx50xgg0zc383jead2s0hm8uym/b7b6svgx50xgg0zc383jead2s0hm8uym
drwxr-xr-x 3 bradrydzewski wheel 102 Dec 12 15:54 .
drwxr-xr-x 3 bradrydzewski wheel 102 Dec 12 15:54 ..
drwxr-xr-x 21 bradrydzewski wheel 714 Dec 12 15:54 src
This does not make sense, because Docker automatically creates the working directory if it does not exist. We can verify this behavior with the below command.
$ docker run -t -i -w /foo/bar/baz alpine:3.8 /bin/sh
This has me wondering why it would behave differently for some clusters, but not others. The only thing I could think of is that some Kubernetes clusters use containerD as the runtime engine instead of Docker? Maybe this could explain the difference in behavior? Can anyone confirm or disprove this theory?
Unfortunately because I cannot reproduce this problem it makes it very difficult to triage. I therefore will need assistance from those experiencing the issue to dig a bit deeper and help me understand why the working directory is not being automatically created inside the volume.
Hopefully we can get to the bottom of this soon