www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <j...@apache.org>
Subject [jira] Created: (INFRA-2173) Create CouchDB BuildBot Instance
Date Tue, 04 Aug 2009 22:10:14 GMT
Create CouchDB BuildBot Instance

                 Key: INFRA-2173
                 URL: https://issues.apache.org/jira/browse/INFRA-2173
             Project: Infrastructure
          Issue Type: Task
      Security Level: public (Regular issues)
          Components: Buildbot
            Reporter: Paul Joseph Davis

CouchDB Build Bot Request

General Outline

1. Two builds per commit - Normal and Coverage
2. Execution of test suite
3. Move generated reports to a public server
4. Harass developers on build failure via [commits|builds]@couchdb.apache.org
   and #couchdb on irc.freenode.org if possible.


* Erlang - http://erlang.org/
  * Verision R13B01 - http://erlang.org/download/otp_src_R13B01.tar.gz
  * Easily built with:
    $ tar -xvzf otp_src_R13B01.tar.gz
    $ cd 
    $ ./configure --enable-threads --enable-smp-support \
    --enable-kernel-poll --enable-hipe --with-ssl
    $ make
    $ make install
  * If kernel poll or HiPE is not supported on the target platform, neither is
    mission critical.
  * Erlang may whine a bit about not having Java or wxWidgets but should compile
    fine without either. CouchDB requires neither.
* Spidermonkey
  * Version 1.7 - http://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz
  * By far the biggest headache of the bunch.
  * Building the library goes something like this:
    $ tar -xvzf js-1.7.0.tar.gz
    $ cd js/src/
    $ make -f Makefile.ref
    $ JS_DIST=/usr/local make -f Makefile.ref export
  * Supposedly, version 1.8.1 has an RC comming. If I were to guess, this is
    the requirement that will change fastest.
* ICU - http://site.icu-project.org/
  * Version 4.0 - http://icu-project.org/download/4.0.html
  * I have absolutely no experience building this. Its always been in package
    manager repositories. The only report I've heard of issues is with versions
    less than 3.2. Current standard versions are generally 4.0 or 4.2
* cURL - http://curl.haxx.se/
  * Version 7.19.5 - http://curl.haxx.se/download/curl-7.19.5.tar.gz
  * Also never built by hand as package manager versions are generally

A brief aside for future planning

The Erlang and Spidermonkey dependencies are the important two. Erlang
development moves along pretty quickly and a fair amount of people tend to
track with each release. Spidermonkey is undergoing some noticeable development
with Tracemonkey (1.8.1) about to be released. Tracemonkey also introduces some
noticeable API changes so having builds using versions on either side of the
break would be appreciated.

A future goal would be to have builds run against multiple versions and combinations of Erlang
and Spidermonkey. Just thought I'd mention that now in
case it affects decisions for software installation.

Test builds on multiple operating systems would also be desirable (including
Windows). I would guess that this is probably the most difficult dependency to 
add, but just in case you're looking for raised hands.

Building CouchDB

Assuming libraries are installed on system paths, it should be as simple as:

  $ ./bootstrap
  $ ./configure
  $ make
  $ make dev
  $ make check

We would also like to have coverage reports generated which require building
the Erlang sources with debug flags. A coverage run looks like this:

  $ ./bootstrap
  $ ERLC_FLAGS=+debug_info ./configure
  $ make
  $ make dev
  $ make cover

The coverage HTML output is placed in the `./cover` directory. Currently this
is the only report that we'd want to have copied to a publicly viewable
location. In the future when we have a stable internal API, we'd look to add
documentation generation similar to the other BuildBot projects.

There are also a few other build combinations that would be in the nice-to-have
but only require different parameters passed through ERLC_FLAGS.

Triggering Commits

Files that trigger a commit are the simple and obvious choices. A simple file
name regular expression might be written as something like:


Ideally, builds would be triggered for each commit to the project's SVN
repository that includes one or more files matching that regular expression. If
that generates too many requests, then if possible backing off to once per
commit but no more than 1 per some defined time period would be preferred.

Notifications of build status

This is obviously a ways off, but we'd probably want to see either a new
mailing list created for build notices (builds@couchdb.apache.org) or have the
notifications sent to the commits@couchdb.apahe.org list.

Notices on the IRC channel (#couchdb on irc.freenode.org) would also be an
excellent addition if they are available. IRC messages would probably be best
for state transitions as opposed to the results of each build, but I would
want to poll the channel before making a final decision.


On behalf of the CouchDB team I'd like to thank the infrastructure team once
again for providing all of the services that they do.

Feel free to email me directly or hop on the #couchdb channel with questions.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message