Some comments in the current guidelines about specs

[ypriverol]

@prvst @sauloal @bgruening @hroest @timosachsenberg @BioDocker/contributors
About this two questions, I have a major question about how we will handle the containers in other repositories. Lot of users and contributors wants to handle their own containers in their repositories.

Making biodocker less centralize system. Some of things that needs to be clear:

• To be a Biodocker container needs to be biodocker compliant.
• The deploy should be done under biodocker hub (DockerHub)

Things that needs to be solve:

• How we can notice from our web/registry/github-container repo that those containers exist.
• How we can be sure those containers works and are ready to be use.

We need to improve our documentation to been able to handle those cases.

[prvst]

I think the two first points are essential. In order to be part of the project, the images must follow most, if no all, requirements and,most importantly, they must be provided by BioDocker hub account. By doing that we can assure a certain level of quality and at the same time, reinforce the "brand" associated with every image. People can still use the images outside the BioDocker hub by building them to end users by themselves, but I think it is very important to distribute them using the "official" hub account.

How we can notice from our web/registry/github-container repo that those containers exist.

Can you explain better this point, I'm not sure if I understood.

How we can be sure those containers works and are ready to be use.

If we want to decentralize, we can still use out official hub account to distribute third-party images. Considering that someone has a new repository with a Dockerfile to be added to BioDocker, we can check if the Dockerfile complaints with the necessary requirements and then we can point the automated build to that repository. The owner will be responsible for the image maintenance, there is no need to clone it into our containers list and if something goes wrong with the build we get a notification from the hub.

[ypriverol]

@prvst Where is defined the first two points?.

[bgruening]

In many of your docker files I see that you change to a biodocker user or that you set as working directory the directory of a tool, but I was wondering is those behaviours are indicated somewhere, are they necessary requirements, etc.

Yeah, we need to be more explicit with this and fine-tune our recommendation. I don't think we enforce to use the biococker user, isn't it?

As a sideline to this, in one of our important use cases — running galaxy with dockerized tools within a container orchestration environment — having the containerised tool running ability bound to be in a defined working directory breaks things. I’m not saying that you’re actively doing this, but if that is the reason for setting the working directory on the docker file, then it would be a problem for us. This is because galaxy needs to control working directories to detect variably named output files. The only case where we see this happening is when the main entrypoint is something like , like Rscript myScript.R (receiving arguments from the outside). Our current solution to this is to wrap this call in shell file, pass arguments to the wrapped call, leave this wrapper in the path and make it executable.

I guess we can add more flexibility to Galaxy, but I would actually fix the Rscript myScript.R example. We should not have this entrypoint, isn't it?

Another question. We are currently building docker files within the our project for a number of metabolomics tools. However, for project reporting statistics and deliverables, we need to keep this under the ownership of the our github organization.

I know this is an entire political decision and I hate it. It makes our work and everyone else just harder. Why does it not count that someone contributed to a already existing community. Ideally you should gain more reputation and visibility if they contribute to biodocker.
That said, if someone really needs to have their own organisation and branding I think we can create a "BioDocker approved" sticker/badge that you can apply to your organisation. We could also setup DockerHub repositories and grant you permissions, again just a lot of work for us that I would like to avoid if possible.

Do you see a way in which we could both host these docker files in our github repo while also making them available at the biodocker repo? Would the git submodules work for this?

I think the hard part is figuring out how we can solve the biodocker dockerhub integration. Do we really want to have two identical images?
Is a biodocker forked repo in your organisation, with modified readme file maybe enough for your funding agency?

I know this user can not do much for such funding-agency requirements, sorry if I sounded too harsh ... such things just make me cry.

Things that needs to be solve:

• How we can notice from our web/registry/github-container repo that those containers exist.

We need a web-page that sits on top of Dockerhub and makes our container searchable.

• How we can be sure those containers works and are ready to be use.

We need to have a strong CI integration like mulled has to build containers and test them.