Support needed to publish docker images to both Docker Hub and ghcr.io?

[ghost]

The main idea is to publish multiple repositories to get some redundancy if one of them change their policy for hosting docker images.

I like to share my thoughts about modifying the build tool to support this.

1. Build images only for one repository and switch to a backup repository only when needed When GNS3 wants to use a different docker repository, besides providing the images the appliances need to be updated and distributed (for example by creating a new GNS3 version). So the change needs some time anyway, there is enough time to rebuild the images for a new repository. In the workflow the logins and the DOCKER_REPOSITORY settings needs to changed.
2. Run the build tool multiple times with different DOCKER_REPOSITORY settings This has the advantage, that the build tool needs no changes. After the first run the build cache should speed up the build, so that the build should not take that much longer. But when building lots of images, the cache could be too small to cache all builds, so lengthy rebuilds can still happen. Furthermore if an image in a backup repository gets deleted and the image in the main repository is still current, only the image for the backup repository is built. That can result in slight differences between master and backup repository, there is no guarantee that the images in the repositories are identical.
3. Support second repository in the build tool The main advantage compared to #​2 is that the cache size is uncritical as the same image for different repositories will be build one after the other. But it has the same drawback, that it can't be guaranteed that the images in the repositories are identical.
4. Support backup repository in the build tool and copy missing images from main to backup The difference to #​3 is, that only missing/outdated images of the main repository are built and uploaded to main and backup repository. Missing images in the backup repository, where the main image is current, are copied from the main to the backup. The GitHub Action images include skopeo, which should be right tool for that.

I am favoring option #​1 and #​4, but I am open for comments.

[grossmj]

Your PRs solved this issue. Thanks again for your contribution :+1:

[grossmj]

Note, the packages published on gns3-registry are private, that must be a organization setting that needs to be changed.

[ghost]

On "normal" (non-organization) Github accounts the packages are public, when the repository is public. So I have to change nothing, when I create packages with GitHub actions.

For organizations I hoped it works the same, but it seems it doesn't. So one time for every package you need to make it public and add the docker repository gns3-repository as its source. I've seen that's done, either by you or automatic by the GitHub action build.

One thing I can't check is the Actions access, within the package settings it must set to the gns3-registry, otherwise my build tools and/or docker build might have issues accessing it within the GitHub Actions. Please verify, that it look similar to this screenshot.

Note, the packages published on gns3-registry are private, that must be a organization setting that needs to be changed.

I haven't found a setting for this, so I fear that at least the public setting has to be done manually once for each new package. But as I'm not part of an organization I don't know what's available in the organization settings.

[grossmj]

For organizations I hoped it works the same, but it seems it doesn't

I just had to have the settings changed for the GNS3 org.

Now everything is public by default: https://github.com/orgs/GNS3/packages?repo_name=gns3-registry

[ghost]

That's good to know, now the GitHub Container Registry ghcr.io should be ready to use. At least as a fallback, if anything happens to docker.com.

[ghost]

Just for reference:

On "normal" (non-organization) Github accounts the packages are public, when the repository is public.

That can be set in the account Settings / Packages. I assume, that if this option is disabled, new packages will be created as private.