CDash:Design
Time storage in DB
CDash stores all dates and time in GMT (also known as UTC) format. Therefore, when a build is submitted to CDash, a conversion is done from the current timezone to GMT. Some timezones are not currently solved by PHP and some other issues might happen, like Australian eastern timezone is expressed as EST which is the same as the American eastern time (EST), creating confusion.
As of CTest 2.6, the unix timestamp is now submitted as part of the XML submission. If present, CDash will use this time, instead of the date/timezone format. This should solve the problem stated above.
Test Timing
Added in CDash 1.0. CDash supports timing defects for tests. CDash keeps in the database a current weighted average of the mean and standard deviation for each test time for each build. In order to keep the computation as light as a process as possible, the following formula is used, involving only the previous build.
newMean = (1-alpha)*oldMean + alpha*currentTime newSD = sqrt((1-alpha)*SD*SD + alpha*(currentTime-newMean)* (currentTime-newMean)
A test is defined as failing if it verifies the following:
if previousSD < thresholdSD then previousSD = thresholdSD. if currentTime > previousMean+multiplier*previousSD.
One can notice that alpha defines the current “window” for the computation. By default alpha is set to 0.3.
Daily Updates
Added in CDash 1.0, daily updates from the repository are stored in the database (instead of polling the CVS/SVN server every time the page was accessed.
The first build of the day triggers the daily updates from the SVN/CVS repository. If the webserver supports PHP_CURL then the request is done asynchronously using curl (calling the dailyupdatescurl.php page), otherwise the request is done synchronously and requires the client to wait until the request is done.
The SQL tables, dailyupdate and dailyupdatefile are used to store the nightly updates.
Map and Geolocation
CDash displays the current geolocation of a given site.
CDash uses the free service from hostip.info to get the geolocation from the IP address of the submitted builds. As a free service, it is not perfect and some IP addresses couldn't be resolved. This is also true for internal IP addresses. Curl support for PHP should be enabled on the webserver.
Every time, a build is submitted, CDash performs a cURL query to hostip.info and store the resulting geolocation in the database.
Graphs
CDash uses flot for the graphing library. Flot is a javascript graph library released under MIT License.
Flot currently doesn't support mouse over event, but it is a feature request on the flot library. As soon as the feature is added to flot, CDash will make use of it.
The graphs are generated from an Ajax request to the database. The fetching time is proportional to the number of entries in the database.
Global Project Revisions
Modern version control tools (svn, git, hg, bzr, ...) track commits to an entire project instead of on each file. Each commit may change many files and directories, and the changes come atomically in one piece. The current CDash change report page is file-based, which works well for cvs (and tolerably for svn) but not for other tools.
In order to support more version control tools, we need a new way to store and present the versions of code being tested.
One important part of this is to have a way to identify specifically a global revision of the project. The following table shows how to do this for some common VCS tools.
| Tool | Specifier | Example |
|---|---|---|
| cvs | <branch>, <date> | ITK-3-4, "2008-06-07 16:34:56 -0400" |
| svn | <dir>, <rev> | trunk/Foo, r1234 |
| git | <sha1> | 184e154429933effddb6bce0a8ee5a6b99fc450c |
| hg | <rev>:<sha1> | 6907:6dcbe191a9b5 |
| bzr | ?? <upstream>:<rev> | some.upstream.net/path/to/repo, r1234 |
