How can I access the current repo context and files from a Docker container action ?

Hello ! I am trying to build a new Docker container action that must interact with the current repo files.
I understand how to setup and initialize my action with Docker, however I do not understand how am i suppose to acces the repository’s files and the current job context Indeed, lets supose that we have a workflow that calls actions/checkout, how can I then acces these files from inside the container ? Do I have to mount a docker volume to GITHUB_WORKSPACE, or does Github Actions provide a better way to do this ?

Thanks in advance !

@obrassard When use a Docker container action in the workflow, it will automatically run with a volume mapping from GITHUB_WORKSPACE (on the runner machine) to /github/workspace (inside container). 

So you could easily get access to your repo files under / github/workspace inside the container.

For example, I want to access to the in my repo,

In my Docker container action >, I could use 

cat /github/workspace/

to show the content of 

cat file.png


Thanks for your great answer !!!

I think this information should be better explained in the GitHub actions documentation. Have a nice day :+1:

1 Like

That doesn’t seem to be the case for me. I’m running the checkout@v2 action before my Docker action but there doesn’t seem to be a /github/workspace directory containing my source files.

In my logs you can see that even though I’m trying to copy my content folder from /github/workspace/content it doesn’t seem to exist.

What am I doing wrong?

That’s part of the container build, not run. The workspace directory is only mounted at run time. Also Docker builds in general can’t access random files, only files in their build context (see the Usage section of the Dockerfile reference). Simply put, you can’t use files from the repository running your action in the Dockerfile, only later in the code that’s running in the resulting container.

Indeed, you won’t have access to /github/workspace during the build phase of your docker image.
This directory is attached (mounted as a docker volume) to your container instance once it is up and running. So, in other words, you will have access to /github/workspace when the action run, not when the image is built. To perform operations on the files in /github/workspace, you could set a shell script as your action entrypoint.

Thanks for your quick reply!

I’ll be honest I don’t fully understand what the difference between the build and run phase is… Could you give me an example of how or at what point I would be able to use my repo files in a docker action?

Or if I can never access to my repo files in a docker action then I don’t really understand why anyone would ever choose docker for their action type. Surely the point in having an action is for it to be able to do something with your source code?

If there is documentation answering this question then please point me towards it, but I’m struggling to understand how actions work in anything more complicated than the basic examples.

The distinction between building a container image and running it is a general Docker (and container) concept, so I’d start with the Docker introduction:

Highly simplified: The Dockerfile describes what should be included in the container image, usually software and maybe supporting files. When the container gets run, the command you set as ENTRYPOINT in the Dockerfile is executed. In Github Actions that command will have access to the build data as described above.

Ok thank you for that. I’ll have a read through the docs.

But is there a reason why docker shouldn’t have access to the repo files during the build phase? I can’t see why this should be the case. Why not make them available during the build phase too?

Because the build is about getting your action code ready to run. You can roughly compare it to compiling a piece of software, and depending on the action code there may be actual compiling involved. Needing the data a user might want to process while compiling a tool doesn’t make sense.

It’d also cause a bunch of technical issues, in particular how to make which files available to the Docker build. That should become clear when you read about the build context in the Docker documentation.

Ok I think that makes sense. I’ll have a look at the docs like you recommended.

Thanks again for your help!

1 Like