[Cdash] Creating "trusted" dashboard configurations

Bill Lorensen bill.lorensen at gmail.com
Fri Sep 3 17:22:46 UTC 2010


I believe that Kitware is working to make it easier for developers to
submit changes that can be tested on a variety of platforms.

Perhaps Bill Hoffman can comment,

Bill

On Fri, Sep 3, 2010 at 12:34 PM, David Doria <daviddoria at gmail.com> wrote:
> 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
> _______________________________________________
> Cdash mailing list
> Cdash at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/cdash
>



More information about the CDash mailing list