Setting up Cassandra database service on TravisCI

At this time of writing TravisCI says that if you want to run a Cassandra service you have to add a cassandra service according to https://docs.travis-ci.com/user/database-setup/#cassandra:

services:
  - cassandra

but if you try to initialize cassandra you might find out that cassandra is not yet ready or running depending on timing.

The solution is:

• a .travis.yml file (see https://github.com/davidemoro/pytest-play-docker/blob/master/.travis.yml) with the cassandra service and a "bash travis/setup_cassandra.sh" command in before_script section
• a travis/setup_cassandra.sh (see https://github.com/davidemoro/pytest-play-docker/blob/master/travis/setup_cassandra.sh) that waits for cassandra up and running (e.g., a sleep 30, a polling loop with max retries implemented in my travis/setup_cassandra.sh script or using docker service) before cqlsh initialization commands

And now cassandra is ready to be used in your tests (for example https://github.com/davidemoro/pytest-play-docker/blob/master/tests/test_cassandra.yml . In this case I'm using using plain yml files thanks to pytest-play)

High quality automated docker hub push using Github, TravisCI and pyup for Python tool distributions

UPDATE 20190611: the article contents are still valid but I definitively switched from pyup to the requires.io service. Why? There were an unexpected error on my pyup project and the support never sent any kind of feedback for weeks (is the project still alive?!). Anyway I happily switched to requires.io: I like the way they manage cumulative pull requests with errored packages and the support is responsive.

Let's say you want to distribute a Python tool with docker using known good dependency versions ready to be used by end users... In this article you will see how to continuously keeping up to date a Docker Hub container with minimal managing effort (because I'm a lazy guy) using github, TravisCI and pyup.

The goal was to reduce as much as possible any manual activity for updates, check all works fine before pushing, minimize build times and keep docker container always secure and updated with a final high quality confidence.

As an example let's see what happens under the hood behind every pytest-play Docker Hub update on the official container https://cloud.docker.com/u/davidemoro/repository/docker/davidemoro/pytest-play (by the way if you are a pytest-play user: did you know that you can use Docker for running pytest-play and that there is a docker container ready to be used on Docker Hub? See a complete and working example here https://davidemoro.blogspot.com/2019/02/api-rest-testing-pytest-play-yaml-chuck-norris.html)

Repositories

The docker build/publish stuff lives on another repository, so https://github.com/davidemoro/pytest-play-docker is the repository that implements the Docker releasing workflow for https://github.com/pytest-dev/pytest-play on Docker Hub (https://hub.docker.com/r/davidemoro/pytest-play).

Workflow

This is the highly automated workflow at this time of writing for the pytest-play publishing on Docker Hub:

• a new pytest-play version or any other pinned sub-dependency is published on PyPI.
  
  By the way pytest-play is automatically released on PyPI thanks to travis when a new tag comes on the master branch.
  If you are curious see https://github.com/pytest-dev/pytest-play/blob/master/.travis.yml. Instead for tags, versions and changelog management I use the always evergreen https://pypi.org/project/zest.releaser described in High quality automated package releases for Python with zest.releaser
• pyup service opens a pull request on github for pytest-play-docker to be merged on master (if you want to reduce the pull requests rate configure pyup properly with a daily or weekly policy, see pyup docs)
• travis runs the build for the above pull request against the pull request branch and pull request status updated (pass or failing)
• receive an email notification about a new pull requests
• if the pull request status is pass merge pull request on master on https://github.com/davidemoro/pytest-play-docker/pulls otherwise investigate
• travis runs tests again on master merge, if the current branch is master and tests passed:
• docker push to Docker Hub on https://hub.docker.com/r/davidemoro/pytest-play

All tests executions run against the docker build so there is a warranty that what is pushed to Docker Hub works fine (it doesn't check only that the build was successful but it runs integration tests against the docker build), so no versions incompatibilities, no integration issues between all the integrated third party pytest-play plugins and no issues due to the operative system integration (e.g., I recently experienced an issue on alpine linux with a pip install psycopg2-binary that apparently worked fine but if you try to import psycopg2 inside your code you get an unexpected import error due to a recent issue reported here https://github.com/psycopg/psycopg2/issues/684).

So now every time you run a command like the following one (see a complete and working example here https://davidemoro.blogspot.com/2019/02/api-rest-testing-pytest-play-yaml-chuck-norris.html):

docker run --rm -v $(pwd):/src davidemoro/pytest-play

you know what was the workflow for every automated docker push for pytest-play.

Acknowledgements

Many thanks to Andrea Ratto for the 10 minutes travis build speedup due to Docker cache, from ~11 minutes to ~1 minute is a huge improvement indeed! It was possible thanks to the docker pull davidemoro/pytest-play command, the build with the --cache-from davidemoro/pytest-play option and running the longest steps in a separate and cacheable step (e.g., the very very long cassandra-driver compilation moved to requirements_cassandra.txt will be executed only if necessary).

Relevant technical details about pytest-play-docker follows (some minor optimizations are still possible saving in terms of final size).

Feedback

Any feedback will be always appreciated.

Do you like the Docker hub push process for pytest-play? Let me know becoming a pytest-play stargazer! Star