Push docker images to ghcr.io alongside DockerHub

[ferferga]

Fixes #6

Added a one-time script that can pull all the images from DockerHub and repush them to ghcr.io

Vue related changes at jellyfin/jellyfin-vue#795

We could likely do the same for the non-combined images (jellyfin-server and jellyfin-web) once we rework the build process of them, as right now they're just useless build artifacts for users and they can't really live standalone.

Setup

All of this requires the system where the scripts are going to run to be logged to the ghcr.io repository. This section of GitHub help is all that's needed for having the pushes working

Additionally, my transfer_ghcr.sh script requires jq in the system for parsing the JSON from DockerHub responses.

Once the images have been pushed for the first time, they need to have their visibility set to Public manually, as they're set to Private by default.

[h1dden-da3m0n]

question regarding the transfere_ghrc.sh: won't the wget calls also take up DockerHub API calls? I mean it should be fine, depending on how many Images you want to 'transfere' (max 100 anonymous 200 free logged in acc) , however that is all I can spot.

I have no power, yet I approve

[ferferga]

@h1dden-da3m0n Honestly I have no idea. According to https://www.docker.com/increase-rate-limits the limits are enforced in a per-image basis but I don't know if that applies to tags in practice. Their REST API documentation had a lot of stuff that wasn't up to date or usable, so I wonder if they meant to include tag pulls here but the wording is just bad.

If it's image based, we only have 4 images and two of them (jellyfin-web and jellyfin-server) can be discarded as they're not useful at all, just build artifacts.

Unfortunately, we don't have a way of really testing this at this massive scale once this is merged and the script it's run by Josh or someone at core to mirror all the stuff. I could test it with my own repositories, but that's not at all the scale Jellyfin has.

[h1dden-da3m0n]

@h1dden-da3m0n Honestly I have no idea. According to https://www.docker.com/increase-rate-limits the limits are enforced in a per-image basis but I don't know if that applies to tags in practice. Their REST API documentation had a lot of stuff that wasn't up to date or usable, so I wonder if they meant to include tag pulls here but the wording is just bad.

If it's image based, we only have 4 images and two of them (jellyfin-web and jellyfin-server) can be discarded as they're not useful at all, just build artifacts.

Unfortunately, we don't have a way of really testing this at this massive scale once this is merged and the script it's run by Josh or someone at core to mirror all the stuff. I could test it with my own repositories, but that's not at all the scale Jellyfin has.

Well I agree in such that the Repository API is a mess and EVERYONE seems to take their own spin (ESPECIALLY REGARDING AUTHENTICATION), however the API Limits are "Best effort" and more importantly GET REQUEST based.

Note that using GET emulates a real pull and will count towards the limit; using HEAD will not, so we will use it in this example. To check your limits, you will need curl, grep, and jq installed.

• Docker - How can I check my current rate

I unfortunately had to deal with this a lot at the end of last year and the start of this year, since I am part of the Infra team in my day job. The way we 'fixed' it was enforcing a registry proxy on all of our CI systems that was only half heartedly done. (Sorry for the story/light rage).

Anyway, depending on what you want to migrate exactly this might be an issue or not I just wanted to make a note since this was a topic I personally hated to deal with.

[ferferga]

Superseded by all the CI migration work tracked here and, in some regard, with #11 and #12. #11 has a better version of this script that only pulls/push when necessary.