How to contribute

Great to have you here. Here are a few ways you can help make this project better! Please let us know if anything feels wrong or incomplete.

Team members

rocker is a project led by Dirk Eddelbuettel and Carl Boettiger. You can contact them by posting an issue here, or by email at rocker-maintainers@eddelbuettel.com. Yelling at @eddelbuettel and @cboettig on Twitter is discouraged.

Learn

This wiki is the primary source of information for the repository.

Brief notes on this project have appeared elsewhere:

• Introducing rocker on the rOpenSci blog and Dirk's blog
• Carl's blog has a set of posts on docker that lead up to the creation of this project
• Dirk's slides from his Docker Chicago Meetup Lightning Talk and his useR! 2015 tutorial.

A detailed manuscript by Carl titled 'An introduction to Docker for reproducible research, with examples from the R environment' is available on arXiv.

Bug reports

If something isn't working as expected for you, let us know by posting an issue here. When reporting your bug, please include some basic details:

• Details of your operating system and the version numbers of docker and other relevant software.
• If you're using boot2docker, also include the version of VirtualBox
• Output from logfiles
• If a very similar bug has already been reported, add a quick "+1" or "I have this problem too". This will help prioritize the most common problems and requests.
• Please setup a profile picture to make yourself recognizable and so we can all get to know each other better.

You can also contribute by looking through the existing issues here and checking if the bug is reproducible, and if it's reproducible in other environments (browsers/OSs). Please add comments to report on your findings!

Adding new features and changing the repository

Proposals for new features, changes and editing or adding documentation are welcome.

• If you are new to contributing on GitHub, these instructions might help you get started
• Open an issue to discuss your proposed addition or change
• Send your pull request to the sandbox branch of the repository. This will mimimize the load on the build server, because all commits on the master trigger a new build.
• If you are writing a new dockerfile, be sure to follow the best practices guide
• Read the description of the automated build chain (below) for more details of how this repository works.

Community

We love to hear how people are using rocker.

• Let us know how you are using rocker in the real world by building something or showing what others have built.
• Write about your project or other people’s projects that user rocker. Show how it’s used in daily life. Take screenshots and make videos!

Automated build chain

This section is of primary interest to rocker developers and contributors. Users should always be able to pull the latest version of any image from the Docker Hub.

Docker images are automatically built on the Docker Hub using the Dockerfiles found here on Github. The deployment chain is as follows:

Build chain

1. We used to make regular commits to the sandbox branch on rocker. These days, making pull requests against the master branch of rocker should be fine as the code is fairly mature.
2. Commits and merges automatically triggers a build of rocker/r-base image on the Docker Hub.
3. Other images on rocker (rocker/r-devel and rocker/rstudio) are marked as inactive on Docker Hub's automated build. This prevents them from starting to build immediately when master is merged, since they depend on r-base and would otherwise build before the latest r-base has finished building. Instead:
4. rocker/rstudio and rocker/r-devel use the Docker Hub's "Repository Links" feature. This automatically triggers a build when rocker/r-base build is finished.
5. Other rocker images on the Docker Hub trigger builds using "Repository Links" of their dependencies. (e.g. rocker/hadleyverse will begin building when rocker/rstudio is finished)

Additional build triggers

1. rocker/r-base (and hence the rest of the rocker images, in sequence) will also build automatically whenever debian:testing is updated (which is every few days, as determined by Debian security updates).
2. Other repositories such as rocker/hadleyverse will also a trigger image builds when the master branch is updated.
3. Repositories that support multiple versions, like rocker/r-ver or rocker/ropensci and rocker/ropensci:dev are all built simultaneously.

Notes

• The timestamp of the last build should be visible on corresponding Docker Hub pages.
• Because each image is rebuilt regularly, apt-get upgrade commands to update other software are unnecessary; while when an image is re-built all the software is updated to latest version available. This is consistent with the recommended Docker best practices.