Best practices and standards for Bioconductor Docker Images
This document aims to outline some of the policies we have set to better maintain the Bioconductor Docker images and also community contributions.
Table of Contents
- How to contribute a new Docker image
- Best Practices and Standards for a Docker image and Dockerfile
- Deprecation policy
How to contribute a new Docker image
The Docker image should be on a GitHub repository owned by the author. The name of the repository should follow the convention
bioconductor_docker_<image-name>. All image names should be lowercase.
The first iteration of the contribution should be developed from the "devel" (master branch) branch of the base image i.e
Once accepted, the repository will be cloned under the Bioconductor organization with full read/write access to the Github repository (https://github.com/Bioconductor).
The Docker Hub organization for Bioconductor will be controlled by the Core team, and builds will be triggered through a push to the GitHub repository which the maintainer will have access to. A new tag for a branch will be added by the Core team at the time of release to enable builds on Docker Hub. We hope to automate some of this in the future.
The author should demonstrate, through Docker Hub builds before acceptance, that the image builds successfully. This guide on Docker Hub is very helpful, https://docs.docker.com/docker-hub/builds/link-source/.
The repository should have an open source license in the LICENSE.txt file. Core Bioconductor packages are typically licensed under Artistic-2.0.
The DESCRIPTION file should contain a field
At the time of RELEASE,
bioconductor/bioconductor_dockerwill provide a new RELEASE_X_Y branch. The core team will create a new branch in the Github repository with the tag
RELEASE_X_Y. If the contributed image depends on
bioconductor/bioconductor_dockerthe tag will be updated to
[ Back to top ]
Best Practices and Standards for a Docker image and Dockerfile
For every repository submitted the Dockerfile is in the top level directory.
Docker images should be based on the
bioconductor/bioconductor_docker:develimages, so that they can inherit all the installed packages and customization, but that is not strictly required.
Images should have a Dockerfile which is clearly defined and documented.
Images should clean up extraneous files created as part of the installation process, to optimize the space used by the image layers. Avoid reinstalling existing software, as this adds another layer without removing the original installtion layer. Please check https://www.fromlatest.io if you have any questions regarding how to optimize the Dockerfile.
The README.md file will act as the vignette for the images. The README.md should have a clear reasoning on what this Dockerfile provides, i.e additional tools or packages on top of bioconductor/bioconductor_docker. Remember there is very little value in providing the same image with a couple of extra packages on top of it as users can install these packages themselves.
Add metadata fields identifying the image in the Dockerfile like below,
LABEL name="bioconductor/bioconductor_docker_<image-name>" \ version="0.99.0" \ url="https://github.com/Bioconductor/bioconductor_docker_<image-name>" \ maintainer="email@example.com" \ description="Description of my image" \ license="Artistic-2.0"
These Metadata fields allow the image to be identified by the user.
Add build badges in your README.md file for the image. This can be easily generated by https://shields.io/category/build, like below
[![Docker Build Status](https://img.shields.io/docker/cloud/build/bioconductor/bioconductor_docker.svg)](https://hub.docker.com/r/bioconductor/bioconductor_docker/builds/)
RELEASE_X_Yimage should be maintained without a build failure. Similar to packages, changes to the RELEASE_X_Y images should be for bug fixes only.
[ Back to top ]
We expect Docker images to follow the same deprecation policy as Bioconductor packages.
Criteria for image deprecation
The image must build successfully at each Bioconductor release. All efforts will be made to keep the image in Bioconductor if the maintainer is actively attempting to fix.
If an image is broken for an extended period of time the maintainer will be given a final 6 week notice. If the image is not fixed by the end of the 6 weeks, an 'End-of-Life' process will be started.
The maintainer listed in the Dockerfile under
LABEL maintainer="firstname.lastname@example.org"must be responsive to questions on the support site, image related emails from users, build failures on Docker Hub and queries from Bioconductor team members. Broken images should be fixed in a timely manner.
If you are unable to fix your image or no longer wish to maintain your image, please contact the Bioc-devel mailing list.
End of Life process
Step 1: Deprecation
:devel image will be marked with a Deprecated warning. The README file
of the Github repository will be updated, along with the build badge.
If at any time prior to the next release, the required criteria are met (e.g., the image returns to active maintenance, perhaps after ‘adoption’ by a third party) the warning is removed.
Step 2: Defunct
:devel image marked Deprecated, at the start of a release cycle will be marked as Defunct.
At the start of the following release cycle, the image will be removed from the Bioconductor organization on Docker Hub.
For more details take a look at the Package deprecation page http://bioconductor.org/developers/package-end-of-life/.
Reversing End of Life
A deprecated image can be un-deprecated if it is fixed before the next Bioconductor release. To have an image un-deprecated, please contact Bioc-devel mailing list.
[ Back to top ]