the-paperless-project/paperless

Continuous Integration for Docker & Vagrant builds

Open

#42 opened on Feb 16, 2016

View on GitHub
 (4 comments) (0 reactions) (0 assignees)Python (7,803 stars) (513 forks)batch import
enhancementhelp wanted

Description

Given both the rapid growth of this project and general convenience, I think a Continuous Integration solution is in order. It would help everyone by:

  1. showing the end-user in the README if the current master builds (which it should!),
  2. checking every PR if it builds correctly, and informing the requester if it didn't,
  3. not allowing a merge of a failed PR (configurable).

Further this should take at least some burden off of @danielquinn's shoulders since a baseline check will already have been performed on the submitted changes.

From what I've seen, Travis CI seems to be the de facto standard on GitHub for automatically building open-source projects for free. There are some alternatives (like drone.io) but they usually don't allow us to install our requirements (like ImageMagick) or have other limitations. While a system like Jenkins could definitely cover all use cases, and I use it personally with great success, it requires a dedicated system to run on.

Travis CI is controlled by a .travis.yml file which has to be located in the root of the repository. This file is a specification for Travis on what steps to perform and what commands to execute in order to build and test an application. The build-environment can be a full VM based on Ubuntu 12.04 or Ubuntu 14.04 or it can be container-based.

I have created a simple .travis.yml to test if and how it works, see feature/travis-ci. I have managed to build Paperless successfully. This build was based on my Docker implementation feature/dockerfile and tested both the building of the Docker image and running of the tests under both Python 3.4 and 3.5.

Building and testing the application directly in the Travis VM without using Docker is of course possible, and Travis allows to test multiple Python-versions automatically. But (a) from what I've seen combining the Travis Python tests with the Docker tests is a hassle and (b) the environment we build up within the Docker container is identical to the one we would build up in the VM.

Ignoring the Dockerfile altogether is of course an option. While this would simplify installing and testing directly in the Travis VM, it would not guarantee that a pull request doesn't break the Dockerfile, which in my eyes should be covered by CI! (Even testing Vagrant seems to be an option.)

Summarized, those seem to be the points for discussion:

  • Should a CI system be introduced?
  • What exactly are the requirements for the CI?
  • Is Travis CI a decent choice? Are there better alternatives?
  • Do we want to cover the Dockerfile and Vagrantfile?

Contributor guide

Tech stack
pythondocker
Domain
ci cddevops
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
DockerTravis CIPython testing
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Review the feature/travis ci branch on the original fork (pitkley/paperless) to understand the proposed .travis.yml configuration. Check the project's current build and test setup, as the repo may have evolved since 2016. Look at the Dockerfile and Vagrantfile to ensure compatibility. Follow up on any discussion in the comments regarding alternative CI services or specific requirements.