Documentation/Labs/CDash Improvements

From Slicer Wiki
Jump to: navigation, search
Home < Documentation < Labs < CDash Improvements

This page documents current limitation of Slicer dashboard and idea to improve them.

Goal

Ensure there is synergy between Slicer community requests and CDash development team

Current Limitations

Slicer nightly/stable dashboard separation

The Slicer4 dashboard page (http://slicer.cdash.org/index.php?project=Slicer4) is really hard and slow to manage due to the large number of submissions.

The nightly and stable builds test different code versions, so they are unrelated: knowing the same test fails on the nightly/stable is not useful information. So, we could reduce the content by 50% by separating nightly and stable submissions into two separate dashboards (e.g., keep Slicer4 for nightly and add a new Slicer4Stable dashboard project for stable).

Source: http://slicer-devel.65872.n3.nabble.com/Slicer-nightly-stable-dashboard-separation-td4035668.html

Extension error pollutes main project error/warning count

See https://github.com/Kitware/CDash/issues/181

Clickable error/warning count on main page listing subproject

On the main page listing Slicer and associated plugins, the error/warning count are not clickable

Subscribe to subproject errors

I would like to get notification if any of the extensions that I maintain have build or test errors or warnings.

Do not rebuild extensions when no updates happened

Factory time is a very precious resource, especially on the windows factory. Currently, all stable extensions are rebuilt every time, even if the Slicer trunk did not change and the extension did not change.

Other documented issues

  • #168 package icon is not displayed on subproject build listed on project page
  • #169 Existing API method should be listed
  • #108 Not all errors are reported when calling "ctest_build() / ctest_submit(PARTS Build)" multiple times in a row