This page is under construction

The Nightly and Continuous build/test of ITK is essential to its survival.


The ITK Dashboard presents dashboard submissions from the ITK community. The dashboards represent unique configurations of hardware platforms, operating systems, compilers, compiler options and ITK options.


Policy

Each dashboard shall present a unique combination of hardware/compiler/OS, optional features and compiler options. The dashboard submitter will monitor the ITK dashboard on a routine basis to make sure that the dashboard is reporting as a Nightly or Continuous build.

Terminology

Build Submission Types

You will see several groups of builds reported on the dashboard. They are as follows:

The average user would want to either submit a Nightly or Experimental build.


Note:

Nightly and Continuous builds will perform the following sequence of steps:

  1. Update (git fetch, git reset)
  2. CMake configuration
  3. Build (compile and link)
  4. Run tests
  5. Submit results to the Dashboard

Experimental builds, on the other hand, will skip the update step, and start with the configuration step.

Build Types (Compilation Modes)

Another option that must be set before submitting a dashboard is the build type. The choices are as follows:

Procedure

The recommended method for dashboard submission is using ctest scripts. Specifically, a small script that includes itk_common.cmake to do the bulk of the work. See here for itk_common.cmake details. (See also the commented notes at the top of that script.)

Preparing a Dashboard Submission

New, easier way

  1. Follow the directions here to get the latest itk_common.cmake.
  2. Write a small ctest script according to the instructions at the top of itk_common.cmake.
    1. ctest -V -S your_script_file
  3. See also, the ITK Bar Camp article.

Scheduling a Dashboard Submission

  1. Dashboard submissions can be automatically run with Cron or Scheduler.
  2. The ITK Nightly start time (from CTestConfig.cmake) is 01:00 UTC
  3. Builds should be scheduled such that they start after the 01:00 UTC Nightly start time (that's 8:00 pm Eastern time in the winter, 9:00 pm Eastern time in the summer, so start builds after 9:00 pm Eastern in your local time and it will always be after the nightly start time all year round...) Dashboard best practice: avoid problems when moving to or from daylight saving time

Advanced Features

Run as a specific user

It is a good idea to create a specific user with limited rights to run the nightly test. For example a user called dashboard. 

  adduser dashboard
  su dashboard

And follow the procedure mentioned above to set up the nighly test. Quota limitation for disk space and limited directory traversal can be applied to this user.

Memory Checker

Coverage

Code coverage can be performed with

These two applications compute code coverage in different ways

Configuring GCOV Coverage


To make this part of a Nightly or Continuous build, it is convenient to incorporate these settings into the CTest script that you are using for driving the build. The typical way of incorporating these option is to insert the following lines 

  COVERAGE_COMMAND:FILEPATH=/usr/bin/gcov-3.4
  CMAKE_CXX_FLAGS:STRING=-g -O0  -fprofile-arcs -ftest-coverage
  CMAKE_C_FLAGS:STRING=-g -O0  -fprofile-arcs -ftest-coverage
  CMAKE_EXE_LINKER_FLAGS:STRING=-g -O0  -fprofile-arcs -ftest-coverage

into the block: 

   SET (CTEST_INITIAL_CACHE "
   ...
   )


Configuring BullsEye Coverage

See instructions at

http://www.itk.org/Wiki/CTest:Coverage#C.2FC.2B.2B_Coverage_with_Bullseye

Style

OS Compiler Debug/Release Static/Shared 32/64 bit Wrapping