[Cdash] Creating "trusted" dashboard configurations
David Doria
daviddoria at gmail.com
Fri Sep 3 16:34:40 UTC 2010
The way I thought CDash helps in the process of contributing to
projects is as follows:
1) A new developer fixes a bug or adds some code
2) He then submits runs an experimental build and confirms everything
looks good on CDash
3) He then sends a link to the repo/branch along with a link to the
experimental dashboard to the developers list or an experienced
developer
4) The experienced developer is convinced that the code didn't break
anything (the dashboard is green (or as green as it was before :) )
and simply needs to look over the code to ensure it seems reasonable
After some recent discussion with some experienced developers, it
seems that step 4 is not usually the case. Questions arise such as
"did the new developer have the right options turned on in their
experimental build?", "which version of XYZ library did their system
have installed?" I'm not sure if this information is made available by
CDash, but that is not the point. The point is that the experienced
developers should have to spend as little time as possible verifying
this type of thing so that all of their effort can be spent looking at
the code. It seems like the current solution is for them to run their
own experimental build! As we all know, for big projects this takes
quite a while. When it is building, surely they will start working on
something else. In the best case, when it finishes building they
return to looking at the bug fix, but it seems reasonably likely that
it will be forgotten about or postponed, etc.
I have two suggestions to try to remedy this:
1) Develop a system by which someone can submit a "trusted" build.
That is, have a cdash script (or multiple) that everyone agrees has
the correct options set for a particular purpose. Then create a hash
(or similar) on this script. When a submission comes in to CDash, if
the hash of the script that generated the build matches any "on file",
it is marked as a "trusted submission".
2) Allow submissions to actually be built on a dedicated machine. That
is, rather than the new developer building on their own machine and
then submitting the result, allow the new developer to submit the CODE
(should be pretty easy and quick to 'upload' now with git) and then
actually build the code on a "trusted machine". This is not a
particularly scalable solution, but I don't see very many experimental
builds, so a simple queue could be created.
Any thoughts on this process or on these suggestions?
Thanks,
David
More information about the CDash
mailing list