To follow up on my original post about a basic static container registry, I’ve created another model that might be more of interest to groups that don’t want to build, test, and deploy all in one place. The organizational registry! It looks exactly the same:

but is serving containers from separate repositories from where the registry is hosted! Here is a modified workflow:

  1. other repositories such as singularityhub/centos serve and build container recipes
  2. a pull request runs a continuous integration workflow to build and upload the container to storage
  3. the workflow finishes by creating a branch named according to the repository name (unique)
  4. the branch push opens or updates a pull request on the repository via this GitHub Action

There are many benefits to the above! For example, the above model affords more specific permissions with respect to who manages individual containers. The above also affords many different methods of builders! You can have one container builder use a remote build service, and send containers to Google Storage, and perhaps another builds and uses storage via Amazon Web Services. The above is a more modular workflow that doesn’t place the burden of building on one single repository.

The Organizational Static Registry

We can summarize the org registry as a modified basic registry that itself doesn’t do any building. It’s a silly GitHub repository that only knows how to deploy it’s content to GitHub pages, and it relies on pull requests to it in order to update that content.

Creating a Connected Repository

If you want details for how to set this up, I’ve updated the documentation here. It comes down to forking the repository, and then generating repositories for your containers that have a continuous integration setup akin to singularityhub/centos. Specifically:

  1. Start with a template such as singularityhub/centos. This will build Singularity containers sent to artifact storage.
  2. Connect the repository to CircleCI
  3. Create a Github Machine User
  4. Proceed as you would to add containers (Singularity recipe files) in your repository.

How Does the namespace Work?

Unlike the basic registry, the organizational registry has a namespace based on the GitHub repositories that submit containers to it! So if you are submitting a container from singularityhub/ubuntu, the container will be served from https://singularityhub.github.io/singularityhub/ubuntu, with manifests and tags under https://singularityhub.github.io/singularityhub/ubuntu/manifests/<tag>. This makes life much easier for the registry, because the namespaces aren’t maintained via randomly generated folder hierarchies, but rather via the GitHub namespace.

How do I create a tag?

Unlike the basic registry, the tags for your containers follow the Singularity Hub standard. The extension of the Singularity file maps to a tag. For example, Singularity will build the tag “latest” and Singularity.pancakes will build the tag pancakes. The rules for interaction with the API to get a container or tag manifest are the same for both kinds of registries.

Next Steps

The registry would then do any testing desired to ensure that the objects exist, content types are valid, etc. I’ll add this testing when I have a more solid example with several build options. I’m optimistic that with remote build services and completely GitHub actions driven workflows, we won’t even need to think about the complexity of communication between different continuous integration services. More to come!



Suggested Citation:
Sochat, Vanessa. "Organizational Static Container Registry." @vsoch (blog), 01 Feb 2019, https://vsoch.github.io/2019/registry-org/ (accessed 22 Dec 24).