[Cdash] Duplicate build entries with CDash 2.0

[Peter Colberg]

On Wed, Feb 08, 2012 at 09:30:26PM -0500, Peter Colberg wrote:
> It turns out revision 2935 causes the duplicated build entries:
> 
> daa7f7b89f31b248d172b05237e2b6dc1052b4c3 is the first bad commit
> commit daa7f7b89f31b248d172b05237e2b6dc1052b4c3
> Author: david.cole <david.cole at 91079597-3006-4846-9bd3-4f3fb3d139a7>
> Date:   Tue Aug 2 21:43:38 2011 +0000
> 
>     ENH: Include updates from related builds (those with the same stamp, siteid and name) not just the one given buildid. When a subproject-based dashboard submits its cycle of subproject builds, all after a single ctest_start call, also typically followed by a single ctest_update call, and then a loop of subproject configure/build/test sequences, we want the updates gathered at the beginning to be reported for each subproject build in non-collapsed viewing mode... This commit achieves that by introducing the get_updates_buildid_clause function, and then using it everywhere the buildupdate and updatefile tables are queried for update related information.
>     
>     git-svn-id: https://www.kitware.com/svn/CDash/trunk@2935 91079597-3006-4846-9bd3-4f3fb3d139a7
> 

A follow-up to the above regression:

I tried to fix the function get_updates_buildid_clause(), by including
“projectid” in the columns of the WHERE clause. Indeed, this fixes the
problem of duplicated build entries between separate *projects*.

However, in our software we also use subprojects, where a subproject
is equivalent to a branch of a git repository, e.g. “master” and
stable branch “0.1.x”. In our nightly ctest script, we have a loop
that executes the complete chain of commands (ctest_start,
ctest_update, …) *for each branch*.

With this setup, I still get duplicated entries, even if projectid is
included in get_updates_buildid_clause(). So for this case the fix
would be to include the subproject ids in get_updates_buildid_clause()
as well. But then the intention of SVN r2935 is completely subverted…

To resolve this issue, could you rethink the way related builds are
implemented? I understand the intention behind SVN r2935, but the
implementation is broken, i.e. it breaks all existing CDash projects
where one build site submits builds with identical name to different
projects and/or subprojects.


For readers stumbling upon this issue, this patch works around it:

Index: cdash/cdash/common.php
===================================================================
--- cdash.orig/cdash/common.php 2012-02-13 17:16:31.122636320 -0500
+++ cdash/cdash/common.php      2012-02-13 17:19:19.382428333 -0500
@@ -2033,11 +2033,7 @@
 
 function get_updates_buildid_clause($buildid_str, $field_str = 'buildid')
   {
-  $buildid_clause = " ".$field_str." IN (SELECT id FROM build ".
-    "WHERE (stamp, siteid, name)=".
-    "(SELECT stamp, siteid, name FROM build WHERE id=".$buildid_str.")) ";
-
-  return $buildid_clause;
+  return $field_str."=".$buildid_str;
   }
 
Thanks,
Peter