<br><br><div class="gmail_quote">On Mon, Feb 13, 2012 at 5:30 PM, Peter Colberg <span dir="ltr"><<a href="mailto:peter@colberg.org">peter@colberg.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Feb 08, 2012 at 09:30:26PM -0500, Peter Colberg wrote:<br>
> It turns out revision 2935 causes the duplicated build entries:<br>
><br>
> daa7f7b89f31b248d172b05237e2b6dc1052b4c3 is the first bad commit<br>
> commit daa7f7b89f31b248d172b05237e2b6dc1052b4c3<br>
> Author: david.cole <david.cole@91079597-3006-4846-9bd3-4f3fb3d139a7><br>
> Date: Tue Aug 2 21:43:38 2011 +0000<br>
><br>
> 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.<br>
><br>
> git-svn-id: <a href="https://www.kitware.com/svn/CDash/trunk@2935" target="_blank">https://www.kitware.com/svn/CDash/trunk@2935</a> 91079597-3006-4846-9bd3-4f3fb3d139a7<br>
><br>
<br>
</div>A follow-up to the above regression:<br>
<br>
I tried to fix the function get_updates_buildid_clause(), by including<br>
“projectid” in the columns of the WHERE clause. Indeed, this fixes the<br>
problem of duplicated build entries between separate *projects*.<br>
<br>
However, in our software we also use subprojects, where a subproject<br>
is equivalent to a branch of a git repository, e.g. “master” and<br>
stable branch “0.1.x”. In our nightly ctest script, we have a loop<br>
that executes the complete chain of commands (ctest_start,<br>
ctest_update, …) *for each branch*.<br>
<br>
With this setup, I still get duplicated entries, even if projectid is<br>
included in get_updates_buildid_clause(). So for this case the fix<br>
would be to include the subproject ids in get_updates_buildid_clause()<br>
as well. But then the intention of SVN r2935 is completely subverted…<br>
<br>
To resolve this issue, could you rethink the way related builds are<br>
implemented? I understand the intention behind SVN r2935, but the<br>
implementation is broken, i.e. it breaks all existing CDash projects<br>
where one build site submits builds with identical name to different<br>
projects and/or subprojects.<br>
<br>
<br>
For readers stumbling upon this issue, this patch works around it:<br>
<br>
Index: cdash/cdash/common.php<br>
===================================================================<br>
--- cdash.orig/cdash/common.php 2012-02-13 17:16:31.122636320 -0500<br>
+++ cdash/cdash/common.php 2012-02-13 17:19:<a href="tel:19.382428333" value="+19382428333">19.382428333</a> -0500<br>
@@ -2033,11 +2033,7 @@<br>
<br>
function get_updates_buildid_clause($buildid_str, $field_str = 'buildid')<br>
{<br>
- $buildid_clause = " ".$field_str." IN (SELECT id FROM build ".<br>
- "WHERE (stamp, siteid, name)=".<br>
- "(SELECT stamp, siteid, name FROM build WHERE id=".$buildid_str.")) ";<br>
-<br>
- return $buildid_clause;<br>
+ return $field_str."=".$buildid_str;<br>
}<br>
<br>
Thanks,<br>
Peter<br>
</blockquote></div><br><div><br></div><div>Try CDash from svn trunk. <span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">get_updates_buildid_clause was eliminated over the weekend...</span></div>
<div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br></span></div>