In workflows, how to use ghcr docker image?


After updating my docker image and pushing to ghcr, the changes are not available when running the workflow!

The workflow looks like:

name: Some name

    branches: [ main ]


    runs-on: ubuntu-latest
        username: ${{ }}
        password: ${{ secrets.PRIVATE_ACCESS_TOKEN }}

The workdir in the docker image is:


I’m still trying to figure out what’s going on, to the point where I stopped relying in the latest tag and used a very specific tag that contains the changes I want. To b more specific, there’s a binary that I added and is available when I check it in my local machine (docker run), but it’s not when running the cloud (github workflow).

Did a lot of tests and even uploading the same image under a different name, to avoid any caching, but same issue.

Locally, when I run the image, I can instantiate it and open a shell and see the binaries etc, but not once in the cloud.

Could you show us exactly how the update and push happens? The way the image is used looks correct (assuming the credentials are), so it’s probably something there.

The Dockerfile is pushed manually to mitigate any issues:

docker build -t image:latest

docker tag hash

docker push

The project requires Rust, Rustup, Cargo, etc. Which is all in the Dockerfile, as tested locally.

For some reason, rustup should be located in /github/home/.cargo, instead of the default cargo installation directory which is /root/.cargo/bin.

This step is done in the Dockerfile, as:

ln -s "/root/.cargo/bin" /github/home/.cargo

Which then, when I do open a shell session locally to the Docker instance, I confirm everything is ok and operates as expected:

docker run -v $(pwd):/github/workdir/ -it /bin/bash

Lists the expected files or symlink when:

ln -ls /github/home

Now, in the cloud, if I do the same as done locally:

    runs-on: ubuntu-latest
        username: ${{ }}
        password: ${{ secrets.PRIVATE_ACCESS_TOKEN }}

      - name: DEBUG
        run: |
          ls -la /github/home

The output is empty or does not have the .cargo symlink!


I understand I can have the Rust Toolchain github action, but if I go with this option, I need to build Rust source code which is extremely slow. I also understand I can use cache by using key names and validation but I just want to use the Docker instance as I have tested locally and not have to include or build certain dependencies.

      - name: Rust toolchain
        uses: actions-rs/toolchain@v1
          toolchain: stable
          target: wasm32-unknown-unknown

Just thought about something that I need to test.

The path I’ve been using in the Docker file is:

ENV PATH="/root/.cargo/bin:${PATH}"

But I’ll now try:

export PATH="$HOME/.cargo/bin:$PATH"

And also:

ln -s "/root/.cargo/bin" "$HOME/.cargo"

Actually this wouldn’t work as effectively, $HOME throws, when running locally:

failed to create symbolic link '/root/.cargo/bin': File exists

So, I guess the original should be alright:

RUN ln -s "/root/.cargo/bin" /github/home/.cargo

And probably this /github/home location is a volume that is mounted automatically maybe?! And so anything I do in advance is effectively removed?! I do remember testing doing the symlink as a step in the github action workflow, but can double check.

This right there is the problem. When using a container as a job container, the runner mounts several directories from the host into the container. /github/home is one of the target directories, which hides anything you might have put there in the container image (check the “Initialize containers” step in your workflow logs).

So if you want your software to be available inside the job container, it really needs to go anywhere but /github/ inside the container image. :slightly_smiling_face:


Thanks! That’s good to know, hope it helps other users.

I have also tried the symlink in the Github Action workflow, but I will double check (what I meant is, during some testing, for alternative solutions). If do it as a step in the workflow, do you think it’ll work?

Do you know when the doc for “Initialize containers” is located? trying to find it

I don’t think there is a specific documentation. I mean you should check the workflow logs, where you can see the exact commands the runner is using. Here’s an example from one of my workflows:

Thank you for letting me know!

1 Like

What a gem, I didn’t know that either!

1 Like