build/buildbot/config/example.xml

   1 <?xml version="1.0" encoding="utf-8"?>
   2
   3 <!--
   4     Name:       example.xml
   5     Purpose:    Buildbot example configuration.
   6     Author:     Mike Wetherell
   7     RCS-ID:     $Id$
   8     Copyright:  (c) 2007 Mike Wetherell
   9     Licence:    wxWidgets licence
  10
  11     There is one xml file such as this per build slave containing a <build>
  12     element for each build the slave runs. Each <build> corresponds to a
  13     column in the waterfall display.
  14
  15     For full documentation see:
  16     http://www.wxwidgets.org/wiki/index.php/Development:_Buildbot
  17 -->
  18
  19 <bot xmlns:xi="http://www.w3.org/2001/XInclude"
  20      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  21      xmlns:exsl="http://exslt.org/common"
  22      xsl:version="1.0">
  23
  24 <!--
  25     Common declarations.
  26 -->
  27 <xi:include href="include.xml" xpointer="xpointer(*/*)"/>
  28
  29 <!--
  30     Notes:
  31
  32     The elements marked 'Unique' below must be unique across all builds on
  33     all slaves.
  34
  35     If a build is currently failing because of something other than a bug in
  36     wxWidgets, e.g. out of space or missing libs, then comment it out, or
  37     add '** Ignore **' to the beginning of the <name>, so that wxWidgets
  38     developers know not to waste time investigating.
  39 -->
  40 <build>
  41     <!--
  42         Unique. Appears as the title in the waterfall display.
  43     -->
  44     <name>Linux x86_64 wxGTK Stable</name>
  45
  46     <!--
  47         Unique. The name of a directory for the bulid. On most slaves must
  48         be a single name, on the Testdrive builds it must be a path such as
  49         '/tmp/wx/td_gtk'.
  50     -->
  51     <builddir>example_gtk</builddir>
  52
  53     <!--
  54         The name of a scheduler that will trigger this build. The schedulers
  55         are usually defined in common.xml, look in there to see if there is
  56         already one you can use, and add a new one if not.
  57
  58         The 'trunk_quick' and 'stable_quick' schedulers currently in
  59         common.xml trigger a build after every source change on the trunk
  60         and stable branches respectively. There are also daily and weekly
  61         schedulers 'daily_6am', 'monday_6am', 'tuesday_6am' and so on.
  62
  63         The <scheduler> element can be omitted, in which case the build
  64         never runs automatically, but can still be triggered manually.
  65         Or you can use several, e.g. you could use two weekly schedulers
  66         that fire on different days to have a build run twice a week.
  67     -->
  68     <scheduler>trunk_quick</scheduler>
  69
  70     <!--
  71         The meaning of <sandbox> is specific to the build slave. There
  72         should be a comment in the slave's configuration file saying if they
  73         are allowed or required. On the testdrive it specifies the remote
  74         machine that will run the bulid.
  75     -->
  76     <sandbox>debug</sandbox>
  77
  78     <!--
  79         You can override the make command the compile steps will use using
  80         this <make> element, if omitted defaults to 'make'. For Windows
  81         builds this becomes the place to put build options as there is no
  82         configure step.
  83     -->
  84     <make>nmake -f makefile.vc SHARED=1 CPPUNIT_CFLAGS=-I\cppunit\include CPPUNIT_LIBS=cppunit.lib</make>
  85
  86     <!--
  87         The build steps.
  88     -->
  89     <steps>
  90         <!--
  91             Check out the sources, by default the trunk branch. Or for a
  92             particular branch or tag, e.g.:
  93                 <checkout branch="{$STABLE_BRANCH}"/>
  94                 <checkout branch="branches/WX_2_6_BRANCH"/>
  95         -->
  96         <checkout/>
  97
  98         <!--
  99             A <shellcommand> build step can be used anywhere you need to run
 100             arbitrary commands not covered by the standard build steps.
 101             <haltOnFailure/> specifies that the whole build fails if this
 102             step fails, without it it continues with the next step anyway.
 103         -->
 104         <shellcommand>
 105             <description>setting up</description>
 106             <descriptionDone>set up</descriptionDone>
 107             <haltOnFailure/>
 108             <command>setup-script</command>
 109         </shellcommand>
 110
 111         <!--
 112             Configure. Options and environment variables can be added with
 113             the 'options' attribute:
 114                 <configure options="-with-foobar CC=cc CXX=CC"/>
 115             Omitted for Windows builds.
 116         -->
 117         <configure/>
 118
 119         <!--
 120             Compile the library. For Windows builds use <compile-msw/>
 121             instead which runs the make command in the 'build\msw'
 122             subdirectory instead of the wxWidgets root.
 123         -->
 124         <compile/>
 125
 126         <!--
 127             Compile subdirectories. There is also <compile-contrib/> for
 128             branches that have contrib.
 129         -->
 130         <compile-samples/>
 131         <compile-utils/>
 132         <compile-tests/>
 133
 134         <!--
 135             Run the test suites. For Windows builds the command to run the
 136             test suite must be overridden, e.g.:
 137                 <run-tests>
 138                     <command>PATH=..\lib\vc_dll;%PATH%</command>
 139                     <command>cd tests</command>
 140                     <command>vc_msw\test</command>
 141                     <command>vc_msw\test_gui</command>
 142                 </run-tests>
 143         -->
 144         <run-tests/>
 145     </steps>
 146 </build>
 147
 148 </bot>