Use GHCR image in uses field of job step?

[abatilo]

I have an image that's being built and pushed to the GHCR.

I'm trying to use that image, which is itself a GitHub Action using the following syntax that's documented:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-the-github-packages-container-registry

- uses: docker://ghcr.io/$owner/$name:$tag

I have the package configured with the settings that allows access by the repository that I'm trying to use. In fact, if I do:

      - name: Login to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - run: |
          docker pull ghcr.io/$owner/$name:$tag

The above will work. However, there's no way for me to do a docker/login-action for the actions that get downloaded when the workflow is being setup.

Is there no way to use private/internal GHCR images as a job step?

[ossanna16]

Hi there @abatilo and welcome to our community! Thank you for asking a great question 🙂

[abatilo]

Thanks @ossanna16. Happy to be here.

[SeanTAllen]

I think this is a bit of broken functionality. I've run into this as well.

When you make an image in GHCR private or internal, you can set the list of repositories that are allowed access to said image.

If you use that image as a job container like:

container:
  image: docker://ghcr.io/example/example:latest

then you don't need to provide credentials to use the image.

However, when doing in uses: the actual authentication error is for getting the image manifest. I suspect that the "allow actions access" was only tested with job containers and not with actions and thus full access isn't granted and the pull fails.

Hopefully this "probably a bug" gets fixed at some point (I've contact GH support) and ideally an option like credentials that you can use with job containers is also provided for uses: docker:// .

If/when I hear back something definitive from GH support, I'll update this discussion.

[abatilo]

That would be lovely @SeanTAllen. I'll update here as well if I hear anything.

[SeanTAllen]

I got a reply from GitHub support. There's no active work being done to support using containers for actions from private container registries. There is internal tracking for the issue (but nothing public). They have noted my interest in the feature and @abatilo's as well. Additionally, they have added a link to this discussion to the internal tracking so if others express a desire to see the feature as part of this discussion, it will be "registered" in some fashion.

For anyone who comes along and is looking for a workaround, I switched my action to being a job container when used from a private container registry. This can work because the container entry can take credentials.

In order to make the change, all your other steps need to be able to run within the environment provided by the action container when it is used as a job container. For me, this meant installing gnu tar in it as other actions used were expecting gnu tar and not the busybox tar I had in the action container.

Then, all inputs supplied by with like:

with:
  fu: bar

need to be supplied as environment variables in the correct form like:

env:
  INPUT_FU: bar

Lastly, the entrypoint for the action container needs to be called directly as the run command for a step in the job container.

You can see an example of this change that I did here: https://github.com/ponylang/appdirs/blob/main/.github/workflows/generate-documentation.yml#L23

Hopefully all this is helpful to some folks in the future until such time as GitHub supports getting action containers from private registries like they do with job containers.

[lhsazevedo]

Just faced this issue right now while migrating from Drone to Github Actions. In our case the registry is self hosted.

Thanks for sharing the reply you got @SeanTAllen.

[aiell0]

Adding a +1 to this, recently came across this today. Pretty disappointing.

[mike-ayres]

This is still an issue?! I'm pretty sure I used a similar feature in gitlab almost a decade ago with AWS ECR... Drop copilot and get this and the fine grained tokens worked out.