[Cdash] Duplicate build entries with CDash 2.0

[David Cole]

On Mon, Feb 13, 2012 at 5:30 PM, Peter Colberg <peter at colberg.org> wrote:

> 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@293591079597-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
>


Try CDash from svn trunk. get_updates_buildid_clause was eliminated over
the weekend...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20120213/55f467d6/attachment-0002.htm>