|
Size: 1187
Comment:
|
Size: 2709
Comment: document current buildbow setup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| The Buildbot master for Fast Downward is located at [[http://buildbot.fast-downward.org/]], and it currently runs Buildbot version 0.7.12. |
The Buildbot master for Fast Downward is located at [[http://buildbot.fast-downward.org/]]. |
| Line 13: | Line 12: |
| Our Buildbot is configured with 4 build types: | Our Buildbot uses eight workers with different operating systems, compilers, and LP solvers: * Ubuntu 16.04, GCC 5.4, CPLEX 12.8 * Ubuntu 16.04, GCC 5.4, no LP solver * Ubuntu 18.04, GCC 8.2, CPLEX 12.8 (We call this worker the foreman and use it for builds that only need to run on a single worker) * Ubuntu 18.04, GCC 8.2, no LP solver * Ubuntu 18.04, clang 3.9, CPLEX 12.8 * Ubuntu 18.04, clang 3.9, no LP solver * Windows 7, VS 2017, CPLEX 12.8 * macOS Sierra, AppleClang 8.0.0, no LP solver |
| Line 15: | Line 22: |
| * Quick - performs an incremental build immediately after each commit * Full - performs an clean build and a quick translator check 5 minutes after each commit * Nightly - performs a small planning test and a big translator check every night * Weekly - performs a big planning test and a big translator check every night |
On every commit on the default branch, we run the following tests * A style check of the code (only on the foreman). If these tests fail, the others are not run. * Build tests on all workers. These are slightly different for the different operating systems * All Linux workers * 32-bit tests: we test an incremental build of the {{{release32}}} configuration, followed by clean builds of the {{{release32}}} and {{{debug32}}} configurations. We then run all our code tests. * 64-bit tests: if the 32-bit builds are successful, we test incremental builds of the {{{release64}}} and {{{debug64}}} configurations. * Autodoc: if the 32-bit builds are successful, we also update our documentation in this wiki. This is run only on the foreman. * Windows * Similar to the Linux setup, we start with in incremental build of the configuration {{{release32nolp}}} (32-bit configuration, ignoring the installed LP solver) followed by clean builds of {{{release32nolp}}} and {{{debug32nolp}}}. We then test clean builds of {{{releasenative}}} and {{{debugnative}}}, that use the native 64-bit build with an LP solver. We do not run any code tests on Windows. * macOC * We test an incremental build of the {{{release32}}} configuration, followed by clean builds of the configurations {{{release32}}}, {{{debug32}}}, {{{release64}}}, and {{{debug64}}}. We then run exit code tests and test on dome benchmark tasks. We do not include translator tests as on Linux, because we don't have a running Python3 installation. |
| Line 20: | Line 34: |
| == Buildbot Operation == Here are some basic commands for the buildbot (master or slave): * Start {{{ buildbot start BASEDIR }}} * Stop {{{ buildbot stop BASEDIR }}} * Reconfig (reread configuration file without restarting) {{{ buildbot reconfig BASEDIR }}} * Restart {{{ buildbot restart BASEDIR }}} BASEDIR is the location of the buildbot configuration file (master.cfg for master, buildbot.tac for slave) |
In addition to the tests that run on every commit, we run a nightly and a weekly test, that both run some default configurations on the first problem of Gripper and Miconic to check for any performance regressions. We also have a builder that can only be triggered manually and recreates the baseline for these nightly/weekly tests. |
Back to developer page.
Buildbot
Buildbot Overview
We use Buildbot for automated building and testing of Fast Downward. The Buildbot master for Fast Downward is located at http://buildbot.fast-downward.org/.
Buildbot Configuration
Our Buildbot uses eight workers with different operating systems, compilers, and LP solvers:
- Ubuntu 16.04, GCC 5.4, CPLEX 12.8
- Ubuntu 16.04, GCC 5.4, no LP solver
- Ubuntu 18.04, GCC 8.2, CPLEX 12.8 (We call this worker the foreman and use it for builds that only need to run on a single worker)
- Ubuntu 18.04, GCC 8.2, no LP solver
- Ubuntu 18.04, clang 3.9, CPLEX 12.8
- Ubuntu 18.04, clang 3.9, no LP solver
- Windows 7, VS 2017, CPLEX 12.8
macOS Sierra, AppleClang 8.0.0, no LP solver
On every commit on the default branch, we run the following tests
- A style check of the code (only on the foreman). If these tests fail, the others are not run.
- Build tests on all workers. These are slightly different for the different operating systems
- All Linux workers
32-bit tests: we test an incremental build of the release32 configuration, followed by clean builds of the release32 and debug32 configurations. We then run all our code tests.
64-bit tests: if the 32-bit builds are successful, we test incremental builds of the release64 and debug64 configurations.
- Autodoc: if the 32-bit builds are successful, we also update our documentation in this wiki. This is run only on the foreman.
- Windows
Similar to the Linux setup, we start with in incremental build of the configuration release32nolp (32-bit configuration, ignoring the installed LP solver) followed by clean builds of release32nolp and debug32nolp. We then test clean builds of releasenative and debugnative, that use the native 64-bit build with an LP solver. We do not run any code tests on Windows.
- macOC
We test an incremental build of the release32 configuration, followed by clean builds of the configurations release32, debug32, release64, and debug64. We then run exit code tests and test on dome benchmark tasks. We do not include translator tests as on Linux, because we don't have a running Python3 installation.
- All Linux workers
In addition to the tests that run on every commit, we run a nightly and a weekly test, that both run some default configurations on the first problem of Gripper and Miconic to check for any performance regressions. We also have a builder that can only be triggered manually and recreates the baseline for these nightly/weekly tests.