Tools: Externalize dockerfile for our base image

[apeltzer]

We currently have our Dockerfile for the nf-core/base image (that we use for all pipelines) in our central nf-core/tools repository. However, that is kind of a bad practice, since we can't tag this properly without conflicting with releases of nf-core/tools.

I, therefore, suggest that we generate a novel repository (e.g. nest, since this is where all of our pipelines "nest" within), to hold the dockerfile. That would make tagging, releasing and building with docker cloud possible quite easily and we don't have these conflicts and can rely on properly tagged base images for our project here.

Any ideas would be appreciated - also comments on this one.

We can even fix certain versions of conda in these base images and have a changelog over here.

[apeltzer]

The miniconda images on docker hub aren't really updated anymore unfortunately.

https://hub.docker.com/r/continuumio/miniconda/tags/

(latest is 4.5.4, but there is already a 4.5.11)

[MaxUlysse]

Why can't we tag the nfcore/base image when releasing a new version of nf-core/tools?

Wouldn't it be easier to fix conda version for a specific nf-core/tools release, and make subsequent updates (or minor release) in the other pipelines, instead of making another repo?

[MaxUlysse]

like:
nf-core/tools - 1.1.1 -> conda 4.5.11
nf-core/tools - 1.2.0 -> conda 4.6.0

[apeltzer]

Well we can do that - but you don't see explicitly which version of conda is in the base image when we tag it along. Having our base image follow the conda version that we use inside of it would simply make that more obvious. I'm fine both ways :-)

[alneberg]

I'm probably misunderstanding something. Are you suggesting we should use the exact same version tag for the base image as they have for conda?

[MaxUlysse]

We can add the conda version in a comment ;-).

We need more people in this discussion, or I will continue having such ideas...

[alneberg]

I think the important part is that it is possible to find out which version of conda (or whatever package) that was used, not that it necessarily needs to be obvious from the image version itself. I think having the base image tags tightly coupled to the tools package versions could work, but if you prefer having a separate repo which can be managed separately, thats also fine.

[ewels]

I think I prefer @MaxUlysse's idea about just tagging the miniconda release for each version of tools. Do we need to do more releases for the base image than we need for the template? If we really need a new version of miniconda then we can simply push a new version of the template, which will also sync out to all downstream pipelines so their dockerfiles will reference the new tag of the base image. I think having a single "upstream" repo with template, tests and base image all synchronised is the most intuitive and simple. I'm kind of keen to go in that direction more than the other (eg. merging the logo into tools etc, fewer repos = better).

[apeltzer]

I don't think we need (much) more releases for the base image than we need for the template, no.

Agreed on having everything in one place - I just wanted to think/discuss these things before doing them, fearing that we might just have some (potentially) unwanted side-effects when performing these kinds of updates.

So I'll just update our base image by incorporating the updated conda version in there and will send a PR to nf-core/tools then.

[apeltzer]

Updated version of conda included in newer base image for a while, so we can close this.