We have a new wiki. The migration is not 100% complete. You can help out by moving pages across. This wiki will exist for as long as there are pages left.

The official documentation has moved to http://docs.couchdb.org — The transition is not 100% complete, but http://docs.couchdb.org should be seen as having the latest info. In some cases, the wiki still has some more or older info on certain topics inside CouchDB.

You need to be added to the ContributorsGroup to edit the wiki. But don't worry! Just email any Mailing List or grab us on IRC and let us know your user name.

CouchDB Continuous Integration

This page explains Apache CouchDB’s Continuous Integration setup at http://ci.couchdb.org:8888/ (this is currently a private setup, all committers can request access. We will open this up gradually)

Authors note: THIS IS A WORK IN PROGRESS, everything might be wrong, all is up for grabs, please help, love, Jan.


The overarching goal here is to allow us to ship more software faster and with more confidence. In particular:

Non Goals

Dependency Matrix

CouchDB 1.4.x:

CouchDB 1.3.x:

CouchDB 1.2.x:

CouchDB 1.1.x:

(not strictly supported, but what the heck) CouchDB 1.0.x:

Operating System Matrix



Since we can’t build against one of multiple installed JS engines, we need a build slave for each tested JS engine.

For multiple Erlang versions, we use “Matrix” builds.


Set up all necessary build slaves. From the above, these are missing today:

Add integration jobs for feature and bug fix branches.

Open up access to the public.

Expand test configuration range (we currently only test one spidermonkey per host os)

Migrate to ci.apache.org.

How can I help?

All this is to get a CouchDB QA team going. So far the developers and users do QA, but no dedicated team takes on the task of caring about QA, creating testing infrastructure, etc. This could be you!

Since this is a non-existent team, you can do anything end everything. You can help shape the

The Build Job

Each one of these varies by build slave (i.e. Operating System and configuration), but what they all do is this:

At this point, we have an apache-couchdb-$VERSION_INFO.tar.gz that is packaged up like a release.tar.gz, its sources have been build successfully and all JS and Erlang tests have been run (with 1.2.0 and earlier, only the Erlang tests were run). THESE ARE NOT OFFICIAL APACHE RELEASES.

Now we created a platform-dependent binary version that unpacks into /tmp that users and devs can run on their systems, given they have the same dependencies in the same places, e.g. to test out new features or verify bug fixes. THESE ARE NOT OFFICIAL APACHE RELEASES.

This is so we can distribute the files easily. We might want to move that to ASF infrastructure as well.

This is so devs get real time info on builds.


What is CI / Continuous Integration?

CI or Continuous Integration is the idea that with ongoing development of a piece of software all sorts of automated tests are run alongside. For CouchDB that means that we set up software that tries to build and test release branches and feature branches while they are being developed on in multiple configurations (e.g. various Erlang versions) on different operating systems.

For more info see https://en.wikipedia.org/wiki/Continuous_integration

Why isn’t this using http://ci.apache.org/?

The goal eventually is running this on official infrastructure. To get there, we needed team members to figure out what needs to be done. To be able to learn all the details, we started with a private installation of Jenkins. We hope to migrate this to ci.apache.org in due time.

The ASF has an OS X Jenkins node we can use. Additionally, we can probably request any flavour of Linux we need. One way forward might be to gather list of requirements and then send an email to infrastructure@apache.org to ask for help.

Why isn’t this using Travis CI?

We’d like multi-OS support, Travis doesn’t provide that (yet).

CI (last edited 2013-06-07 10:18:27 by 178)