See also the related issue787.

I think this one is done. Please reopen if you think it should be reopened.

We mentioned it might be good to run some light tests on the built Singularity 
/ Container images that we build. A possible start point for that could be the 
`make-ipc-submission` script that (used to?) lives in the misc folder

If we go forward with this, it may be useful to support docker in addition to
singularity due to its wider use.

> Is there a way to update the usage instructions on
Singularity hub
Umm  cannot find one, but the issue should be solved once we provide a "by default" image 
which gets pulled whenever no particular tag is specified.

> Also, how do you like the idea of adding the mercurial revision of the main repo
as a tag to the meta data of the container?

Sounds very good, I'll see how to best implement that.

That works, thanks. Is there a way to update the usage instructions on
Singularity hub (https://www.singularity-hub.org/collections/1067/usage)?
Because they do not mention the tag and just following them produces the error
below.

Also, how do you like the idea of adding the mercurial revision of the main repo
as a tag to the meta data of the container? This way, you could query the
container to find out when and how it was built.

Yes, there's no "default" fast-downward image yet, so you have to pull with the full tag 
name, e.g.

singularity pull shub://gfrances/fast-downward:18.06

As for the Singularity Hub error message, no idea what it refers to, but I'll have a closer 
look.

I tried pulling the image and got an error:

> singularity pull shub://gfrances/fast-downward
ERROR Cannot find image. Is your capitalization correct?

Clicking on the name of the container on the website also showed an error:
  We had an issue retrieving files for this container! Try another build?

Is the image still building?

Just a quick update on this. I have set up a repo with the appropriate Singularity configuration files and scripts:

https://github.com/gfrances/fast-downward


The repo is automatically monitored by Singularity Hub to rebuild all of the Singularity images upon new commits:

https://www.singularity-hub.org/collections/1067

Additionally, the repo is also monitored by Travis to test that all images are correctly built and can be run on a simple blocksworld 
instance under different Singularity versions:

https://travis-ci.com/gfrances/fast-downward

This is temporary and should be moved to the "official" aibasel Github account once we decide which revision we want to release and polish 
the remaining details. All of this assuming that we're quick enough before Microsoft takes over Github and forces all of the hosted code to 
be migrated to Visual C#, of course :-)

Good point. Yes, that's similar to the Docker hub, which (if properly 
configured) 
builds the whole image on their servers each time you push some changes to the 
github 
repo (i.e. the repo where all container recipes, etc. live, NOT the main fast 
downward 
repo). It should be easy to automate the whole process so that creating a new 
fast-
downward tagged container equates to simply indicating which revision we want 
to create 
the image from.

While looking into Singularity for the IPC I came across https://singularity-hub.org
This is a registry of Singularity containers that is integrated with github. One
way to go would be to create a team account on github, add a repository and push
the Singularity script from issue770 into it (only the file, not the Fast
Downward source code). We could then register on singularity hub and connect the
accounts. The container would be build on their servers and people could use it
with something like

singularity run shub://aibasel/fast-downward

As far as I know, singularity hub supports branches and tags but I haven't
looked into it further. Docker has something analogous (https://hub.docker.com/)
but I know even less about it.

This is a followup to issue770.

We'd like to provide a ready-made Fast Downward Singularity container which would allow (linux) 
end users to download and run the planner both locally and on cluster environments with one or two 
commands (plus of course the installation of singularity), without having to worry about 
dependencies.

Beyond the singularity recipes in themselves, which are simple and already in place from issue770, 
this issue should take care of:
- Discussing and implementing what exactly we want to include in the supoprted image(s).
- Discussing what kind of support / release cycle we provide for this.
- Automating and documenting the build process of the containers.
- Documenting the usage of the resulting containers, both locally and/or in cluster environments.
- Eventually deciding whether it would make sense to provide support for this within Lab 
experiments.