Dist folder not found COPY command docker with GithHub Actions

I don’t get it, I even ran ls dist during my GitHub Action CI Build which shows it’s there but my Dockerfile copy command fails:

Dockerfile

FROM node:14.8.0-alpine
ENV PORT 8080
WORKDIR dist
RUN yarn
COPY dist /dist
CMD [ "yarn", "start" ]

also tried COPY ./dist /dist

I assume I’m in the right context with my copy command specifying dist in the current directory local to the build VM when I’m in a CI workflow?

note that dist is coming from an artifact that I download right before it tries to build the image:

 - uses: actions/download-artifact@v2
        with:
          name: dist-artifact
          path: dist

The Dockerfile COPY documentation mentions that destination directories must be written with a / at the end. So try this:

COPY dist/ /dist/

Thanks tried it. No luck:

Guaging from the error it looks like it’s trying to get it from /var/lib/docker/tmp/docker-builder905973708/dist. What is that? Is that the github workspace context? What is this compared to the context from where I run ls dist in my actual CI job?

Also what I don’t understand is this
https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions

WORKDIR

GitHub sets the working directory path in the GITHUB_WORKSPACE environment variable. It’s recommended to not use the WORKDIR instruction in your Dockerfile . Before the action executes, GitHub will mount the GITHUB_WORKSPACE directory on top of anything that was at that location in the Docker image and set GITHUB_WORKSPACE as the working directory. For more information, see “Using environment variables” and the WORKDIR reference in the Docker documentation.

Why would I even want that and how would I even know what that absolute path even looks like if I need to reference it outside the context of GitHub Actions, lets say I wanted to pull the image down locally and understand what the working directory looks like after the image is actually created?

That documentation is about creating Dockerfile Actions, not general Docker usage in your builds. But it makes me wonder if using the WORKDIR dist instruction before actually creating the dist directory (with the COPY instruction) messes things up somehow.

1 Like

I’ve tried taking out WORKDIR dist and actually the last run I had taken that out when trying your suggestion and also tried with it in. Either way it failed still.

That should be the directory where the image layer is being built, so the destination. What confuses me is that usually Docker creates target directories as needed automatically, but that doesn’t seem to be happening here (which is odd). You could try

RUN mkdir /dist

before the COPY instruction to make sure the directory exists.

mkdir: can't create directory '/dist': File exists

well that’s a good sign but then why do I get the error during the Docker build :slight_smile:

Any chance there already is a file (not directory) called dist? That’d explain why Docker doesn’t create a directory either…

no because I can ls dist and it shows its contents, if you see the original post - look at the job

That’s the dist/ in your sources. I mean if there already is a /dist file inside the container, at the time the COPY instruction runs.

I highly doubt it. This is an image from docker, I doubt they have a dist built in already in the image. There wouldn’t be a reason to have a dist file. And even if there was a dist folder I should be able to copy to it no matter what.

Also put a run command to see what my context was so ran the pwd command:

Step 5/9 : RUN pwd
 ---> Running in 101565af4c0a
/dist

Removing intermediate container 101565af4c0a

 ---> 8fca22bfc2f4

Step 6/9 : run ls -l

[41](https://github.com/dschinkel/we-do-tdd/runs/1080782233?check_suite_focus=true#step:9:41) ---> Running in 2d1626259fdf
check_suite_focus=true#step:9:42)total 0

Removing intermediate container 2d1626259fdf
Step 7/9 : COPY dist /dist

Also one thing I’m doing is I upload the dist directory in a previous job to an artifact. That artifact I download as I mentioned above in my build job which brings that dist directory back down right before I run docker build

- uses: actions/upload-artifact@v2
  with:
    name: dist-artifact
    path: ./dist

not sure why it’s saying 489 files though on the initial artifact upload for just the dist folder which has only like 8 files in it:

I also wonder if downloading the artifact has anything to do with my problem. I know if I don’t download the artifact I have no dist directory in source, so it must be working…

I explored the file system in my container:




I feel like this run command which shows I have dist downloaded from the artifact:

- uses: actions/download-artifact@v2
  with:
    name: dist-artifact
    path: dist
- run: ls dist

which outputs exactly what I expected from the downloaded dist directory from the artifact:

feed.xml
index.html
lib
package.json
scripts
server

The pwd command for that context shows /home/runner/work/we-do-tdd/we-do-tdd
which does not match up with the relative path/context the Cstrong textOPY command is looking at.

I feel like the context of source for the COPY command is looking somewhere else, the /var/lib/docker/tmp/docker-builder190756412/dist which /var/lib/docker/tmp/docker-builder190756412/ is not the same context as the run command above possibly which is the GitHub workspace

This is starting to smell like an issue with the Docker build context. Are you by any chance run the Docker build with a different working directory than the download-artifact step? If so, the downloaded dist/ directory won’t be part of the Docker build context.

Are you by any chance run the Docker build with a different working directory than the download-artifact step?

what do you mean? I tell artifact to output the artifact content to ./dist. I do a -run: ls dist and I see it’s indeed there. I then try toCOPY dist in my dockerfile.

Sigh so I told it to copy the artifacts into a different directory (e.g. final or app) instead of dist. It worked. I don’t know why I can’t use the foldername dist with COPY in this case. So weird.

1 Like