Hi all,

At $DAYJOB, we’re looking to make use of Github Actions as our CI/CD flow. To do what we need to do, we’re making use of Docker to build our software across our repositories.

At the moment, we have a set of actions in our ~/.github/workflows/build.yml file:

 steps:
    - uses: actions/checkout@v2
      with:
        repo-token: ${{ secrets.READ_TOKEN }}
    - name: Docker Login
      run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{ secrets.READ_TOKEN }}
    - name: Pulling docker image
      run: docker pull docker.pkg.github.com/repo:latest
    - name: Build Package
      run: 'docker build -t package .'

The above works, but we have some concerns:

• This environment in Docker is self-contained – there’s no way of referencing anything outside of it, and as such we cannot therefore make use of third-party integrations, as we can’t access anything from within the Docker container;
• We cannot make use of https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer since the container: directive only seems to be applicable to container images hosted on either Docker Hub or some other publicly-hosted site.

We’re reluctant to want to add all of our deployment logic within the Docker container. I cannot for the life of me believe that the container: block is only accessible for public Docker images. Why wouldn’t it be the case that the container: block can access images stored on Github’s own Package site?

Without the ability to reference Github’s own package store via a container: block, essentually means that we cannot therefore set up mounted volumes and other things, which therefore makes our life slightly more difficult, and we’d like to avoid this.

We want to be able to mount volumes from these Docker containers, as the documentation suggests. Without Github supporting accessing its own Package stores, this seems nonsensical.

Any thoughts much appreciated.