Hi Dean, thanks for feed back - Good questions.
Why fail rather than rebuild if the configuration is missing? Well we think like this: In the case where we need to make the choice, the user obviously asked for a reuse - not a rebuild. Potentially a rebuild can take a long time - so it's likely that our guess will not always capture the users intend or wish. Therefore we choose to fail the build and print to the log what happened - simply because it's faster, and this way we're not assuming anything. Then the user (yes - there IS a human involved in this feature) can schedule another rebuild, only this time he explicitly asks for a rebuild - not a reuse.
You are right about your assumptions regarding the UI (we will present a mock-up of what we have in mind very soon) but in large: A rebuild action that takes you to a new form listing all the results in the matrix from the previous build, each cell in the matrix now has a small checkbox attached to it. The user checks the builds in the matrix he/she wants to rebuild - the other ones are reused. There will be short cuts like "select all failed", "select all unstable" ...etc. When the user hits submit, the choices are traversed and all the builds that shall be reused will have the ReuseRun attribute set.
Our plan is to extend the ability to reuse a build in the core (as presented here) and then we will release the form that utilizes it as a seperate (new) plugin.
...leading to your third question - or concern: It requires a knowning human! Yes! The scenario we see for this reuse/rebuild feature is:
In a large matrix some (most) configurations has succeeded, a few have failed or are unstable. Going through the logs it appears that it's due to the slaves configuration or abilities that something went wrong (say a process hung or a network connection was lost or it failed to get a license to tool it depended on....) Now you don't want to rebuild the entire matrix again (imagine that it takes several hours to do that). You just pick the failed builds and ask to reuse the successful ones. We imagine that the configurations that are rerun will still honour all the various other settings of the job, thus if the job picks latest commit on a branch, and there is a new commit - then you are right it's a different build then before.
We imagine that users must take the necessary steps in their job configurations to avoid mistakes like this to happen. In our setup we're building a named commit, so it's safe - for us
The thing is, we realize that the behaviour we're looking for might be special, but the aproach to how we implemented it (in AbstractBuild and Run) is generic. Other plugins could use the same feature to make different behaviour - either by contributing to our plugin or by creating a new one. The design should support that no more extensions are needed in the core to make either work.
Hmmm - But to avoid making future changes to the core on behalf of others in the future would rather rebuild than fail the build, then I guess we could extend the ReuseRun object to be able to carry such information (rebuildIfMissing) and act accordingly. We could set it to FALSE as default and get the same behaviour. Would that work?
Again, Thanks for feed back, it's very welcome!