Skip to content
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

Closed
b-ehlers opened this issue Jun 4, 2023 · 6 comments
Closed

Comments

@b-ehlers
Copy link
Contributor

b-ehlers commented Jun 4, 2023

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
Copy link
Member

grossmj commented Jun 19, 2023

Your PRs solved this issue. Thanks again for your contribution 👍

@grossmj grossmj closed this as completed Jun 19, 2023
@grossmj
Copy link
Member

grossmj commented Jun 19, 2023

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

@b-ehlers
Copy link
Contributor Author

b-ehlers commented Jun 19, 2023

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.

Package_settings_Manage_Actions_access

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
Copy link
Member

grossmj commented Jun 20, 2023

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.

image007

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

@b-ehlers
Copy link
Contributor Author

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.

@b-ehlers
Copy link
Contributor Author

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.

settings_packages

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants