couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rnewson <>
Subject [GitHub] couchdb-ci pull request: [wip] Docker container Ubuntu 14.04/Erlan...
Date Tue, 22 Dec 2015 15:40:04 GMT
Github user rnewson commented on a diff in the pull request:
    --- Diff: readme.markdown ---
    @@ -3,44 +3,80 @@ CouchDB CI Setup
     Mission statement: Create a new continuous integration infrastructure for the CouchDB
    -For the background and goals, see this [thread](
on the couchdb-dev mailing list.
    +For the background and goals, see
    -This is the repository for the automated creation of the CouchDB CI infrastructure. Well,
at least it will be when it has grown up. This might take a while, though. Right now, it's
just a bunch of Ansible scripts, a Vagrantfile and a Veewee definition.
    +* this [thread](
on the couchdb-dev mailing list and
    +* this [ASF Infra ticket](
    -See the readme files in folder `baseboxes` (for docs on building the base boxes) and
the section about Vagrant below (for docs on how to spin up the setup locally).
    +*Remark: Throughout this repository we use the terms "master"/"worker" for the Jenkins
build machines, whereas the Jenkins documentation uses the terms "master"/"slave".*
    -Fair warning: This is very much work in progress.
    +The main purpose of this repository is to provide a number of Docker containers that
the ASF infrastructure team can use in their Jenkins setups and which are capable of building
CouchDB. The idea is to provide containers for a number of different operating systems and
Erlang versions to make sure CouchDB builds and runs on all supported setups.
    -Current state:
    +The current (rough) plan for the build matrix is this:
    -- [x] install bare Jenkins master with Ansible
    -- [x] install and configure nginx
    -- [x] create CouchDB build job in Jenkins via Ansible
    -- [x] switch to master-worker Jenkins setup
    -- [x] use ntp server for master and workers
    -- [ ] Use SCM sync plug-in to manage job configs
    -    *
    -    *
    -- [ ] enable auth for Jenkins
    -- [ ] actually fetch CouchDB from VCS
    -- [ ] all apt-get commands should pin a specific version, in the base box definition
as well as in Ansible. How?
    -- [ ] create an additional Ubuntu worker with an older Erlang version
    -- [ ] create another base box (different linux distro) for a third worker
    -- [ ] talk to Infra people
    +**OS/Erlang**       | **R14B04** | **R16B03-1** | **17.5** | **18.x**
    +**Ubuntu 14.04**    | ?          | -            | -        | WIP
    +**Ubuntu latest ?** | ?          | -            | -        | -
    +**Debian 7**        | ?          | -            | -        | -
    +**Debian 8**        | ?          | -            | -        | -
    +**OS X latest**     | ?          | -            | -        | -
    +**Free BSD**        | ?          | -            | -        | -
    +**Windows**         | ?          | -            | -        | -
    -*Remark: Throughout this repository we use the terms "master"/"worker" for the Jenkins
build machines, whereas the Jenkins documentation uses the terms "master"/"slave".*
    +### Open questions
    +* AFAIK Erlang 14 support will be dropped soon-ish, so I'm not sure if it is worth the
effort to do anything for that.
    +* Which 18.x Erlang version is to be used? I heard someone saying 18.0 once, but that
was before 18.1 and 18.2 were available, so I guess it makes more sense to always use the
latest 18.x to see if changes in Erlang 18 breaks CouchDB.
    --- End diff --
    while it's important to test against each OS's stock erlang install (where available),
I think it's important to test various erlang versions too, we need to know that our software
works on previous and future versions (relative to what's in any stable OS release). Take
travis as an example, we can list any (or all) erlang versions there. The main deficiency
of travis is that we can't also have an OS axis to that matrix.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message