Deploy

Singularity Commands

Deploying your workflow on the command line is as simple as using the Singularity software. In one line, we can run, shell into, or pull our image from Singularity Hub:

singularity shell shub://vsoch/singularity-images
singularity run shub://vsoch/singularity-images
singularity pull shub://vsoch/singularity-images

We currently do not support importing entire images (we don't do layers like Docker, these are full blown images). You can also pull your image via it's unique id, although this is a less intuitive use case:

singularity pull shub://53

Tags and Branches

Remember that a single Github repository is called a "Collection," and is associated with multiple container builds, one per commit to be exact. By default, we build from the master branch when you first connect your repository, and if you want to add another branch to build, you can do this in your collection view:

You can then turn on (and off) branches to build. This is also helpful if you want to disable a branch for building, while testing, or something like that:

When you need to reference a branch from the command line using the singularity software, you would use the shub:// uri prefix. By default, when we don't specify anything, we will pull the latest, which means the most recent build across branches. This may not be master.

singularity pull shub://vsoch/singularity-images
Progress |===================================| 100.0% 
Done. Container is at: ./vsoch-singularity-images-master.img

This call is equivalent to:

singularity pull shub://vsoch/singularity-images:latest
Progress |===================================| 100.0% 
Done. Container is at: ./vsoch-singularity-images-master.img

You can ask to pull a different branch, for example:

singularity pull shub://vsoch/singularity-images:mongo
Progress |===================================| 100.0% 
Done. Container is at: ./vsoch-singularity-images-mongo.img

Basically, the image tag is associated with the branch where the Singularity file is located, at it's root. This is a simple strategy that optimizes for the following:

• one commit is associated with one Singularity file, and one container
• if Singularity Hub explodes, we can rebuild the entire thing without any extra information about "where in the repo" and "what is the file called"
• the user doesn't need to specify anything special (like the file name or location)

For the Singularity Registry that we are developing, there will likely be more programmatic access, and integration with more types of webhooks.

Naming your Container

By default, your container will be named with the format <username>-<container>-<branch>.img. The file is stored compressed, and decompressed when you pull it. If you anticipate serving multiple versions of your image, you might want a custom name. Singularity Hub supports naming images by hash, commit, or a custom name.

Name by Hash

To name your image by it's md5sum content hash, you can do the following:

singularity pull --hash shub://vsoch/hello-world
Progress |===================================| 100.0% 
Done. Container is at: ./0a25c3e72619acd51e9ebe3753c46ec3.img

Is it really the hash?

md5sum 0a25c3e72619acd51e9ebe3753c46ec3.img
0a25c3e72619acd51e9ebe3753c46ec3  0a25c3e72619acd51e9ebe3753c46ec3.img

Name by Commit

You can also name by the Github commit, which is nice to go back and find it again.

singularity pull --commit shub://vsoch/hello-world
Progress |===================================| 100.0% 
Done. Container is at: ./e279432e6d3962777bb7b5e8d54f30f4347d867e.img

Custom name

Finally, you just might want to name it something entirely different. You can do that with --name:

singularity pull --name meatballs.img shub://vsoch/hello-world
Progress |===================================| 100.0% 
Done. Container is at: ./meatballs.img