search

sopel-irc / docker-sopel

:whale: Officially Unofficial™ Docker container for Sopel, a Python IRC bot
https://hub.docker.com/r/sopelirc/sopel
12 stars 6 forks source link

WIP: Add GHCR build option & update build to include ARM64 #57

Open adamus1red opened 4 months ago

adamus1red commented 4 months ago

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.

dgw commented 4 months ago

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:

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.)

adamus1red commented 4 months ago

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.

dgw commented 4 months ago

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.

HumorBaby commented 4 months ago

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 :stuck_out_tongue_winking_eye: to find the true culprit: @adamus1red !!
adamus1red commented 4 months ago

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 :stuck_out_tongue_winking_eye: 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