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.