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:49:46 GMT

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

ASF GitHub Bot commented on INFRA-10126:
----------------------------------------

Github user rnewson commented on a diff in the pull request:

    https://github.com/apache/couchdb-ci/pull/1#discussion_r48265648
  
    --- Diff: readme.markdown ---
    @@ -3,44 +3,80 @@ CouchDB CI Setup
     
     Mission statement: Create a new continuous integration infrastructure for the CouchDB
project.
     
    -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.
    +* There is no CentOS/RHEL there, shouldn't it be added?
    +* Do we run a CouchDB build on all combinations on each commit? This would probably be
too much for the ASF Infra build systems. Do we build them once a day? We need to find a good
balance between early feedback and resource consumption here.
    +* Do we even want to build the master branch or some other branch/tag? I guess the master
branch would be most interesting for now, but not entirely sure. Also, it might make sense
to make the branch/tag parameterizable so we could also use this to create releases from a
specific tag etc.
    +* What exactly do we do in each Jenkins build? Just build CouchDB? Also build docs? Start
CouchDB? Run some test suite?
    --- End diff --
    
    build couchdb, build docs, run all test suites.
    
    The 'build docs' step is very onerous, taking quite a while. If possible, we'd avoid building
docs again if they haven't changed since last time, though that might be difficult to achieve.


> 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
OSes.
> 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
(v6.3.4#6332)

Mime
View raw message