GitHub Container Registry (ghcr.io): LIST and SET-VISIBILITY apis?

Does GHCR have REST APIs for listing the packages for an organization (presumably by package type)? I seen comments from Sept 2020 that this was on your TODO list.

We also need a REST API that can change the visibility of a package.

We’re currently screen-scraping GitHub.com to workaround this but that’s super slow and fragile since the site keeps changing.

1 Like

We don’t have REST APIs for this yet but its on our list to do. We’re waiting on an internal API to roll out and then we’ll be able to create this.

We don’t have this yet either but we’re in the design phase for it right now. Can tell us more about how you plan to use it?

There are many ways to do this but here are two options we’re currently looking at:

  1. Default the Actions GITHUB_TOKEN to Admin of a Container upon creation of the container; currently it only gets write. This would allow the GITHUB_TOKEN to change the visibility of the container and / or update team user and membership via REST APIs. Additionally the token could downgrade its own privs to write such that future tokens couldn’t use Admin privs. We would expect usage to be: Create container, adjust permissions of new container, downgrade permissions against container, only write to container from then on.

  2. (This one is likely required either way) Create a new scope for PATs packages:admin which is required for using the Container admin REST APIs. With this PAT users can admin Containers they have admin access to via the REST API.

Would love to hear additional thoughts on these or other approaches and especially how you plan or are using the REST APIs.

Sorry for the delay getting back to you, I’ve been heads-down on a project and let my inbox get out of control.

So we’re building an open source Kubernetes distribution over at GitHub - nforgeio/neonKUBE: Projects for neonFORGE, LLC. and to improve cluster setup reliability and speed, we’re prebuilding the Kubernetes node VM images to include everything required including the Kubernetes and other binaries as well all of the required container images (over 90 containers required now). This means that user cluster nodes won’t need to pull container images during cluster creation, possibly being impacted by source registry throttling (i.e. by DockerHub) or network issues.

We need to build two sets of container images during this process that land in two different GitHub package registries. The first are essentially copies of other opensource container images which we call base images and the second are tweaked copies of the base images we call setup images which are what we preload on the VM images.

We have GitHub workflows to manage this that we’d like to go something like:

  1. Remove all of the base container images from the base image registry
  2. Rebuild and publish all of the base images (e.g. to Packages · neonkube-base-dev · GitHub)
  3. Make all of the base images public
  4. Build the setup container images from the base images and publish (e.g. to Packages · neonkube-dev · GitHub)
  5. Make all of the setup container images public
  6. Build our VM images from the setup images

We want to be able to delete all of the base images first because it’s too easy to leave a reference to an old base container image in our scripts and deleting all of the old base container images will at result in a not found error in the build workflows so we’ll know there’s a problem.

We need to be able to automate changing the visibility to public for both the base and setup images since they’ll are initially private after they are first pushed to GHCR.

For other projects, we’d like our GitHub workflows to be able to automatically publish new public container images without having to go back and manually make them public via the portal.