[Cdash] Creating "trusted" dashboard configurations

[David Cole]

There is a new feature in CDash (available as "alpha" or so in svn trunk)
called "Build Management" or "Scheduled Builds" that will eventually allow
something like what you're asking about in this thread.

Look for an article describing how to try out the feature coming up in a
future issue of "The Source" newsletter.

And see the wiki page about it here:
http://public.kitware.com/Wiki/CDash:Build_Management

Eventually, there should be a way for somebody who has a proposed change to
go enter a field in a web page and click a button that says "test this build
for me on all available platforms..."


HTH,
David


On Fri, Sep 3, 2010 at 1:22 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

> 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
> >
> _______________________________________________
> Cdash mailing list
> Cdash at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/cdash
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cdash/attachments/20100907/efad2b21/attachment-0002.htm>