I see the class javadoc for that class but how would I use that to actually aggregate the junit tests to report in the build-flow plugin?
Is it also possible to discourage people in the documentation and yet leave the workspace there so its possible? On Fri, Aug 30, 2013 at 9:22 AM, nicolas de loof <[email protected]>wrote: > I indeed removed workspace support especially to discourage such a "write > some custom jenkins code using DSL" approach. > build-flow is about orchestrating jobs, not creating custom plugins > > junit aggregator is using the original location for junit results, and > dynamically aggregating. It doesn't copy to local project. > > > 2013/8/30 John Russell <[email protected]> > >> Teilo, When did build flow stop having a workspace? I finally got this >> to work by archiving all of the junit files from the downstream jobs onto >> the master, running build-flow on the master, and directly copying the >> files from the archive of the downstream build to build flow and running >> the junit results post build step. >> >> So this won't work anymore? If there is no workspace how would any junit >> result post build step work? >> >> >> On Friday, August 30, 2013 4:14:04 AM UTC-4, teilo wrote: >>> >>> The BuildFlow doesn't use a workspace anymore[1] - so your workaround >>> most likely won't work as you expect. >>> >>> I'm not convinced that this is a good thing as like you I would like to >>> show test results in the main flow job - not have another job that is just >>> aggregate & report. >>> >>> On Monday, 12 August 2013 20:17:54 UTC+1, John Russell wrote: >>>> >>>> Do you guys have any idea how to pull files, specifically test results, >>>> from the jobs started in a build flow up to the build flow job itself so it >>>> can be the one that presents all of the test results? >>>> >>>> I presume that if I can copy them from the slaves up to the workspace >>>> of the build flow build that the post build step of processing the test >>>> results will get them all. Any thoughts on how to get those files back >>>> to the master? >>>> >>>> On Thursday, January 3, 2013 2:30:31 AM UTC-5, Nicolas De loof wrote: >>>>> >>>>> sure, rescue handle whatever happens in gard block, that has no >>>>> restriction on nested content >>>>> >>>>> 2013/1/3 Patrick van der Velde <[email protected]> >>>>> >>>>>> Thanks for that suggestion. One question about the guard statement. >>>>>> Can it handle multiple statements? i.e. is the following allowed? >>>>>> >>>>>> guard { >>>>>> build("job1") >>>>>> build("job2") >>>>>> } rescue { >>>>>> build("finaljob") >>>>>> } >>>>>> >>>>>> or even this >>>>>> >>>>>> guard { >>>>>> parallel( >>>>>> { build("job1a") }, >>>>>> { build("job2a") }, >>>>>> ) >>>>>> >>>>>> parallel( >>>>>> { build("job1b") }, >>>>>> { build("job2b") }, >>>>>> ) >>>>>> } rescue { >>>>>> build("finaljob") >>>>>> } >>>>>> >>>>>> My script looks a bit like that last one but when I tried putting a >>>>>> guard clause around it I got the following error: >>>>>> >>>>>> >>>>>> >>>>>> ERROR: Failed to run DSL Scriptgroovy.lang.**MissingMethodException >>>>>> <http://stacktrace.jenkins-ci.org/search?query=groovy.lang.MissingMethodException>: >>>>>> No signature of method: >>>>>> com.cloudbees.plugins.flow.**FlowDelegate.rescue() is applicable for >>>>>> argument types: (Script1$_run_closure1_**closure3) values: >>>>>> >>>>>> >>>>>> Removing the guard clause made it work. So I'm guessing guard can >>>>>> only handle 1 item? >>>>>> >>>>>> Thanks >>>>>> >>>>>> Petrik >>>>>> >>>>>> >>>>>> On Wed, Jan 2, 2013 at 10:16 PM, nicolas de loof < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> use gard+rescue so you can execute a post-job even when some jobs >>>>>>> are unstable >>>>>>> >>>>>>> >>>>>>> 2013/1/2 Patrick <[email protected]> >>>>>>> >>>>>>>> Ok I'm going to have to amend this answer. My idea of having a >>>>>>>> separate job at the end to gather the results would work if it wasn't >>>>>>>> for >>>>>>>> the fact that the build flow plugin kills the build as soon as one of >>>>>>>> the >>>>>>>> jobs fails. That means I only can get the results if the build works >>>>>>>> which >>>>>>>> is not what I want. I want the results gathering to always take place, >>>>>>>> even >>>>>>>> if the all the build jobs fail. Any way to achieve this? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Petrik >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, 2 January 2013 11:46:54 UTC+13, Patrick wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Mmm ok, I guess I could create a separate job to gather all the >>>>>>>>> test results. Thanks for the advice :) >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Petrik >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-users/MX29Ld8upCs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
