[Cdash] ctest_submit(PARTS ...) ordering issue

[Michele Caramello]

I apologise if this is not the right list (I was undecided between this and
ctest AT cmake.org).

I learned about the ctest(PARTS addition to cmake 2.7.2x when I read this
article http://www.kitware.com/products/html/CDashSubprojects.html and I
found it an useful and interesting feature.
I decided to put it to use although my projects are so small that the
benefits of a staggered submission is negligible compare to the legacy bulk
submission with the plain old ctest_submit() command.

I updated my *Nightly* ctest script to perform a ctest_submit of the
corresponding step that was just completed. The work flow is standard
(Update, Configure, Build) and my submission sequence was: Notes, Update,
Configure, Build.

When I looked at CDash, I found that the Build was the only step correctly
visualized and no trace of Note, Update, or Configure.
As puzzling as it was, I tried a few times, modified a few things, and
eventually ended up using ctest_submit(PARTS Notes Update Configure Build)
which worked, instead of the single steps submissions.
When analysing the output of ctest with -VV, I noticed that the Build.xml
file was submitted first, no matter what the ordering of the parameters for
the PARTS parameter was: that didn't tell me much, initially.

Moving on, I tried breaking down the ctest_submit back into the single
steps pieces to experiment a little.  I eventually came to the conclusion
that the Build step must be submitted first in order for the others to
appear correctly on the dashboard.

Having access to the actual CDash mysql database, I queried the entries by
submitting the steps one by one manually.  It seems to me (although I must
admit neither I looked at the php code too well nor I am an expert,
therefore I might be completely out of track) that the entries in the
index.php?project=PROJECT_NAME page all refer back to the build IDs from
the build table of the database.  I found the 2 build2update and build2note
tables to be the only way one can correlate a build ID to an update ID and
a note, respectively, while the configure table stores the buildid
information.

I am wondering if this speaks of CDash needing a build ID available (and
therefore an entry in the build table as provided by the Build step) prior
to submitting Notes, Update, and/or Configure steps to be able to
cross-correlate the info correctly?
If so, could there be a workaround consisting of perhaps submitting an stub
Build step first to allow any ordering of the submit steps (the actual
Build step would come later in the game and perhaps overwrite the previous
Build info used as stub?  Would that even be possible?

I am looking forward to hearing your thoughts.
Thanks you and Regards,

Michele Caramello
Software Testing Engineering Manager,
MotionProcessing Business Unit*
Inven**Sense**, Inc.**
*(O) 408 - 988 - 7339 x126
Email: mcaramello at invensense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20120508/6e7da443/attachment-0002.htm>