www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (INFRA-10126) CI infrastructure for CouchDB
Date Tue, 22 Dec 2015 15:40:46 GMT

    [ https://issues.apache.org/jira/browse/INFRA-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068267#comment-15068267

ASF GitHub Bot commented on INFRA-10126:

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](https://www.mail-archive.com/dev%40couchdb.apache.org/msg43591.html)
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](https://www.mail-archive.com/dev%40couchdb.apache.org/msg43591.html)
on the couchdb-dev mailing list and
    +* this [ASF Infra ticket](https://issues.apache.org/jira/browse/INFRA-10126).
    -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
    -    * http://stackoverflow.com/questions/27138043/jenkins-scm-sync-configuration-plugin-in-docker-wont-talk-to-github
    -    * https://cburgmer.wordpress.com/2013/01/02/tracking-configuration-changes-in-jenkins/
    -- [ ] 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.

> CI infrastructure for CouchDB
> -----------------------------
>                 Key: INFRA-10126
>                 URL: https://issues.apache.org/jira/browse/INFRA-10126
>             Project: Infrastructure
>          Issue Type: Task
>      Security Level: public(Regular issues) 
>            Reporter: Bastian
>            Assignee: Andrew Bayer
> The CouchDB project wants to up their CI game. Right now there is only an undermaintained
Jenkins installation on a box in Jan Lehnhardt's flat. The goal is to build and test CouchDB
on as many different OSes and Erlang versions as possible. In the end, this will probably
a matrix of build slaves. I volunteered to help with that/take care of that. I already started
to create an Ansible project that provisions a Jenkins server and several slaves for different
> But in the end this will probably need to run on some "official" ASF CI infrastructure.
> The two options I see are
> 1) Integrate this into the existing Jenkins infrastructure?
> 2) Run it on different VMs provided by the ASF infra team?
> I read some of the docs at https://cwiki.apache.org/confluence/display/REEF/Continuous+Integration+Setup
and saw that the usual way is to maintain the job configs manually. This might be quite a
lot of effort since we will need a large number of jobs (for the matrix of configurations).
We plan to automate as much as possible, even the job configs and the slave configs etc. Of
course, this might conflict with the existing Jenkins setup.
> Which of the two options is viable? What is the best way to proceed here?
> Kind regards
>   Bastian

This message was sent by Atlassian JIRA

View raw message