This is the last in a series of posts related to creating a testing container for Biopython using Docker.
In the previous post we developed a container that allows you to have a complete, fully functional environment for Biopython.
Our objective now is different: We want to have a container to help do integration testing for Biopython. That is a completely different kind of animal:
Buildbot installation can be done by adding something like this:
RUN apt-get install -y buildbot-slave RUN buildslave create-slave biopython testing.open-bio.org:9989 CHANGEUSER CHANGEPASS
Notice that you need to change the username and password on the code (CHANGEUSER, CHANGEPASS). This will have to be agreed beforehand with the buildbot system administrator. This also means that you cannot use the Dockerfile from the Internet directly. You have to download and manually edit it. Alternative approaches would be appreciated, BTW.
This kind of container is different from the previous one, where everything was prepared for a user to login and do interactive work inside the container. Here, when you fire up the container it goes on to its business (testing).
In Docker that is achieved by creating an ENTRYPOINT:
ENTRYPOINT bash entrypoint.sh
entrypoint.sh should include everything needed to start up the server (for example, the database servers that on the previous post were started on .bashrc, should here go into entrypoint.sh). Importantly, if you have a daemon server (i.e., that goes into the background) you have to keep the entrypoint running or the container will terminate. So, in our case we will have the following file:
service postgresql start service mysql start export DIALIGN2_DIR=/tmp buildslave start biopython tail -f biopython/twistd.log #To hold things
This series of tutorials was made by a Docker newbie. While I hope this will help others with their docker installations, there might be sub-optimal solutions here (I would appreciate if you point me in the right direction).
The Biopython docker work will continue here. Updates can be found there.
Remember, while you can directly run the container from the previous blog post, the testing container will require you to a) download the container file b) edit username and password c) then you can run it.