-
Notifications
You must be signed in to change notification settings - Fork 9
Release Notes
This release will follow the official release of Singularity 2.4. Changes include the following (some still under testing and development).
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.
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.
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
Need help? submit an issue and let us know!