Singularity Hub has a default builder option to build automatically. This means that after you connect a repository, each time that you commit Singularity Hub will look for new recipes. The logic is the following:

• we filter down to new commits since the last push
• of the previous commits, if any of them have files added or updated that match the patternSingularity orSingularity.<tag>, we consider this a change to a Singularity Recipe that warrants rebuild.

When we finish the above steps, we have a basic dictionary of contenders that we've found. For example. here we have aSingularity Recipe at the base of the repository, and a second of the same name in a subfolder.

     {'Singularity': {                      'commit': 'bdcdb2ba436d43229dc5ee296d85dedc5aee6f5a',                      'date': '2017-09-10T02:51:16Z',                      'name': 'singularityhub/hello-world',                      'url': 'https://github.com/singularityhub/hello-world/raw/bdcdb2ba436d43229dc5ee296d85dedc5aee6f5a/Singularity'                      },     'subfolder/Singularity': {                      'commit': '3f4d63cadba1b3a6867868f9a85417751baba521',                      'date': '2017-07-08T02:43:06Z',                      'name': 'singularityhub/hello-world',                       'url': 'https://github.com/singularityhub/hello-world/raw/3f4d63cadba1b3a6867868f9a85417751baba521/subfolder/Singularity'                       }    }

If you are thinking "there is a conflict!" you are correct. The recipe files are named equivalently, and would both produce a containershub://vsoch/hello-world:latest. Thus, to resolve any conflicts (e.g., two files in different folders both namedSingularity.tag the most recent takes preference. For the above, we would build the recipe at the base of the repo, because it is dated more recently.

Once we have a list of recipe files associated with commits, the builders need to decide to create a new container, or replace an old one. The logic works as follows:

• if a container with the same tag, name, branch, and collection is not found, this means we build, and we build a new container.
• if containers are found with these same matching identifiers but they are frozen, we build a new container. The version is specified by both the commit id (the container's commit) and the hash (the container's hash).
• if a previous container is found and it'snot frozen, we replace it with the new build.
• if a container is found and (regardless of frozen status) the tag is latest, we build over it. It doesn't make sense to freeze a "latest."