Release Notes

Singularity Hub v2.0

This release will follow the official release of Singularity 2.4. Changes include the following (some still under testing and development).

Container Collections

Singularity recipes As was requested by many, this new version will support multiple container recipes in a repository. The location of the recipes is not important, but rather, the naming of the files. All files that start with Singularity will be found recursively.

Branches Branches are no longer the way to specify a tag. As before, you can add and remove branches from building in your container collection, and while you can easily find the branch with the final container metadata, the branch is not relevant for the container's unique resource identifier. In other words, don't expect to serve two equivalently named images from different branches. Thus, as best practice, we recommend that you build from fewer (or just master) or a production branch to not create confusion.

Tags The extension of the Singularity Recipe file (e.g., Singularity.tag) corresponds now to the tag. A Singularity file without a tag is considered latest. For example, given a repository named hello-world under user vsoch, all of these "different" files will be considered to specify building the container with uri shub://vsoch/hello-world:latest:

hello-world/
    Singularity
    Singularity.latest
    subfolder/
        Singularity
        Singularity.latest

If you have conflicts in terms of names in the same repository, the file that is newest is used to build the image Thus, it is suggested best practice to not have repeated files.

Container Freezes The current Singularity Hub would build a new container for every commit, and save it regardless of your good (or poor) container cleanup hygiene. To add a level of explicitness to container builds, the default for a container is now to be ephemeral - meaning if I push the same URI twice, it will over-ride the first container. But never fear! Singularity Hub is importantly focused on reproducibility, so you have the ability now to "FREEZE" individual containers from your container collection view. Given a frozen container, a subsequent build will not override the container, but will create a new container with the updated commit. The frozen container is then best references with it's complete address, eg:

shub://vsoch/hello-world:tag@commit

Latest Latest is a tag that you aren't allowed to freeze. It doesn't really make sense.

Deployment Options

With version 1.0, you had one option - to build on each commit or disable entirely. This new version provides several options:

automatic: is the default and previously used option. All commits are assessed for new recipes, and then a new container is built for the commit. Previous containers with the same unique resource identifier (e.g. vsoch/hello-world:pasta) that are not frozen are re-created. New containers are created given a found frozen container. Conflicts with recipe names in the same repository are resolved by the date of the most recent file. You have the ability to re-trigger any build given that a build parameter has been changed (e.g., debug mode on).

deployment: If you use continuous integration to test and then issue a deployment commit, Singularity Hub (when using this option) will only build containers that have the deployment status. All other commits are ignored.

manual: If you preference is to connect the repository and manually trigger builds, this is now possible. To deploy manually, the automatic building is disabled.

Cloud Space

We are proud to announce support from Google for a new Singularity Hub cloud space! This will hopefully mean better integration with tools to do cool things with your containers. It also means a substantial amount of work with regard to the infrastructure, broadly including the following:

migration of databases and images in storage the new Singularity Hub will build more secure, smaller squashfs images, and so we are encouraging users to build images afresh without migrating over old images from storage. For those users that wish to keep collections and old images, a form will be sent out to specify this preference, and the migration done carefully (manually) by @vsoch. Containers that are migrated will have a status of Frozen.

Tools

Usage and Favorites Metrics are important! To better track container usage, a complete log of downloads via the API is kept, so you can easily see how many requests have been issued to use your containers. To assess favorites, we now give each collection a star, and as a user you can star your favorite.

More coming soon! I need to eat dinner.

Apps

Container Size Treemap