-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support needed to publish docker images to both Docker Hub and ghcr.io? #772
Comments
Your PRs solved this issue. Thanks again for your contribution 👍 |
Note, the packages published on gns3-registry are private, that must be a organization setting that needs to be changed. |
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.
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. |
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 |
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. |
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.
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: