The repository is for a static site built from Jupyter notebooks. The notebooks are converted using build/build.py (Python3) which, for each post, builds a Docker image, along with a manifest, starts a corresponding container with the post notebook directory mounted, so now there is cross communication once that container is spawned. That container uses nbconvert to convert the notebook to Markdown. One step of nbconvert 's conversion involves creating a supporting file directory. This fails on Travis due to a permission issue. You might be thinking what kind of permission issue?
chmod u+x
chown
Well, in attempting to debug this problem, I found that the ownership and permissions of the repo are the same on my local machine and Travis (with my username switched for travis ) before running Docker. (Which is kind of neat), despite this, inside the mounted volume of the Docker container, the ownerships are different:
Local:
drwxrwxr-x 3 montana 1000 4096 April 7 19:56 .
drwsrwsr-x 1 montana users 4096 April 7 21:51 ..
-rw-rw-r-- 1 montana 1000 105 April 7 09:57 Dockerfile
drwxr-xr-x 2 montana 1000 4096 April 7 12:09 .ipynb_checkpoints
-rw-r--r-- 1 montana 1000 154229 April 7 12:28 post.ipynb
Travis:
drwxrwxr-x 2 2000 2000 4096 April 7 19:58 .
drwsrwsr-x 1 montana users 4096 April 7 16:37 ..
-rw-rw-r-- 1 montana 2000 101 April 7 19:58 Dockerfile
-rw-rw-r-- 1 2000 2000 35271 April 7 19:58 post.ipynb
Both my local machine and Travis are running Ubuntu 20.04, have the same version of Docker, and all other tools come from Conda so in theory, they should behave the same. I am struggling to understand where this difference in ownership is coming from. Then it hit me.
If you set the permissions of your local path (/path/on/host) as 777 (via chown), that will also be propagated to the mounting point, no permission error will be thrown regardless of the user that Docker uses to create those files.
After that, you’ll be free to restore permissions, if needed. To test this:
docker run -u $(id -u)
Happy building!
-Montana