Update dockerfiles to new release/devel, fix build for metabolomics

[sneumann]

Hi, here's another set of commits. These build on https://hub.docker.com/r/sneumann/

General:

• Change config.yml to use current release/devel branches
• Disable including ReportingTools and others depending on OrganismDbi which doesn't exist yet in devel
• use libgsl-dev instead of libgsl0-dev

Metabolomics:

• Re-enable ChemmineR which builds now

Don't hesitate to ask if I missed/messed up anything.

Yours, Steffen

[sneumann]

Hi, the official BioC docker images were built an hour ago, but the proteomics is still very old, presumably the build failed and metabolomics didn't show up, so possibly also failed. => Is there any way I can see the output of the build process to help fixing that ? A cheap hack would be if the output logs were simply directed to a file on disk of the web server. Yours, Steffen

[dtenenba]

The machine is inside the FHCRC firewall, so even if the build log was served by the web server you would not be able to see it.

Basically if there is a single error in building any of the images, the whole process failed. I think it failed well before getting to metabolomics.

I think that everything about the way the bioc docker images are built could/should be overhauled, however the bioc core group (which I left in July) is understaffed and overworked at the moment. Are you interested in taking on some of this work?

Very broadly, this is what I think should be done:

• Stop using this custom ruby-based build system and start using docker hub automated builds. One benefit of this would be that anyone would be able to see the build output
• The way we build images based on assay type (microarray, proteomics, etc) results in really big images which makes them less than usable. We need to think of a better way to divide up the images. Perhaps instead of picking every package with a given biocView, we need to curate and be less democratic. Whatever is done here should definitely be done in consultation with (and with the approval of) the bioc core team, since it's potentially controversial.

I think there should be an image that contains many common system (OS) level dependencies (without getting too large). And then individual images oriented towards specific workflows could be built on top of that. Perhaps we could have a process to welcome contributed images from the community.

Interested in your thoughts...

[sneumann]

Hi Dan et al,

thanks for still responding :-) I would not offer to single-handedly take over docker maintainership in BioC. But definitely willing to give a hand here and there.

We at http://phenomenal-h2020.eu/ will make use of (among others) containers with R stuff in it, so there is a pool of people willing and capable of helping. The rake build works nicely if I point it at https://hub.docker.com/r/sneumann/ for image upload.

The automated builds are an interesting idea. One'd need to have one repo per image, and there would have to be regular automated pushes to trigger the daily autobuilds. The repos with the Dockerfiles would have to mimic the versioning of devel and releases.

I would still keep the granularity at the Views level, possibly providing an additional mechanism so that people can easily create their own custom image sets.

Pity about that understaffing at BioC-HQ, if letters of support were needed I guess you could have hundreds if that helped.

Yours, Steffen

[dtenenba]

Thanks for the feedback. Staffing levels are improving but people are still getting up to speed on core tasks and unfortunately maintaining this is not (yet) a high priority.