Based on the build data from https://github.com/sopel-irc/docker-sopel/actions/runs/9383410081

Tags for non-default python (i.e. 3.11)

"tags": [
      "ghcr.io/sopel-irc/sopel:8-py3.11",
      "ghcr.io/sopel-irc/sopel:8.0-py3.11",
      "ghcr.io/sopel-irc/sopel:8.0.0-py3.11"
    ]

Tags for default python 3.12

"tags": [
      "ghcr.io/sopel-irc/sopel:8-py3.12",
      "ghcr.io/sopel-irc/sopel:8.0-py3.12",
      "ghcr.io/sopel-irc/sopel:8.0.0-py3.12",
      "ghcr.io/sopel-irc/sopel:8-py3",
      "ghcr.io/sopel-irc/sopel:8.0-py3",
      "ghcr.io/sopel-irc/sopel:8.0.0-py3",
      "ghcr.io/sopel-irc/sopel:8",
      "ghcr.io/sopel-irc/sopel:8.0",
      "ghcr.io/sopel-irc/sopel:8.0.0",
      "ghcr.io/sopel-irc/sopel:latest"
    ],

I believe the hub tags are not showing as the secret value is not exposed to contributer builds. On my own the tags for ghcr and docker hub are shown as being created.

I believe the hub tags are not showing as the secret value is not exposed to contributer builds.

Most likely, yes. I don't know why @HumorBaby implemented the image name as a secret, but I'd guess that it's because non-encrypted variables didn't exist until 2023. We could just… change the Docker Hub image name to a variable.

The little I know about GHCR tells me that we are meant to use the sopel-irc namespace, because the workflow runs in that organization and you can only push images within your own namespace, so it might not make sense to use a variable there.

Unless something a little more complicated would make sense? Could have three variables:

• DOCKER_HUB_NAMESPACE
• GHCR_NAMESPACE
• CONTAINER_NAME

Yielding Docker tags like $DOCKER_HUB_NAMESPACE/$CONTAINER_NAME and GHCR tags like $GHCR_NAMESPACE/$CONTAINER_NAME. But that sounds overly complicated to me. Is there actually any reason for the image names not to be a static part of the YAML, other than the fact that they now appear in multiple places? (One can't DRY out the multiple references to a secret/variable, but in the unlikely event we need to change image names the var makes it very slightly easier to update.)

Is there actually any reason for the image names not to be a static part of the YAML, other than the fact that they now appear in multiple places? (One can't DRY out the multiple references to a secret/variable, but in the unlikely event we need to change image names the var makes it very slightly easier to update.)

It breaks builds on forks if it isn't configurable or using a variable. Since it'll try to push to sopel-irc namespace without being permissioned for it.

That's fair. So the GHCR build should keep using github.repository_owner, and the Docker Hub builds should keep using a variable if people creating their own forks is a supported use case.

Would it help if I set a new DOCKER_HUB_IMAGE_NAME variable for you to use in this updated workflow? There's no reason for the name to be secret; the resulting image is public, after all.

I don't know why @HumorBaby implemented the image name as a secret, but I'd guess that it's becaus…

I don't know why @HumorBaby implemented the image name as a secret, but I'd guess that it's becaus…

*_Ahem_*, have a gander at the blame/history for the workflow 😜 to find the true culprit:

@adamus1red !!

Probably when I complained about my build failing every time I did a push and getting an email about it