Lower-casing `jobs.<job_id>.container.image`

Hi there—

First of all: This issue is not about building a Docker image, and naming it after the repository when ${{ github.repository }} has uppercase characters. There are plenty of reports of that already,¹ and a very straightforward solution (use a current version of the docker/build-and-push action, which will do the sanitizing for you).

It is, for a change, about using such image in a workflow, for example:

      image: ghcr.io/${{ repository_owner }}/foo:bar

An error occurs during workflow setup (in the Initialize containers step, which is prior to any workflow step):

/usr/bin/docker --config /home/runner/work/... pull ghcr.io/Its-Me/foo:bar
  invalid reference format: repository name must be lowercase

The issue can be solved with a prior job, on which to depend, that performs the transformation, as in:


    needs: lowercasing
      image: ghcr.io/${{ needs.lowercasing.outputs.owner }}/foo:bar

      owner: ${{ steps.owner.outputs.result }}
    - id: owner
      run: echo "::set-output name=result::${REPOSITORY_OWNER,,}"
        REPOSITORY_OWNER: ${{ github.repository_owner }}

This implies, however, and additional job for every workflow that wants the image, and to the best of my knowledge cannot be done as a step in job_id, because the name of the image is needed before the job starts.

Two final comments:

  1. To give some context about our setup, we need this working because of cross-org forks (we don’t want to hardcode any org name)

  2. Contrary to the other, very common issue (building and pushing an image), in which workflow authors directly interact with Docker—here it is the Github workflow itself that is making the interaction.

    The image field is directly owned by Github workflow syntax. If Github is case-preserving (which is nice, actually), then it’d also be nice that it took ownership of that fact here, in this field, knowing to lowercase an input that, very commonly, will be expanded from said caes-preserving metadata (via ${{ github... }} context).

    I understand the workaround, but it seems to me UX could be better here. Thank you!

P.S.: As for workaround, I think I might create org-wide secrets named repository_owner, and be done with it:

image: ghcr.io/${{ secrets.repository_owner }}/foo:bar  # 💁



(¹) I had some links but as a new user I’m only allowed 2, it seems. I will post them in a comment, if allowed.