First - you'd probably want to redirect output to other files - very large console logs come with problems. Second - the use of wait (on Unix) should prevent process leaks. Wait is documented in the bash manual.
Thanks, Danny On Monday, 19 March 2012 08:46:34 UTC, intelchen wrote: > > > If I run several things in background, Jenkins may not capture the > output of these commands. > Do you have experiences about using this > https://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build > ? > It is easy for me to put everything available in a single job. Then it > would be a very large job. It would take a long time to get the results.:( > That is my *real *problem here. > > On Saturday, March 17, 2012 1:54:27 AM UTC+8, sti wrote: >> >> I typically try to run as much in one job as possible to minimize the >> number of jobs. I use these advanced unix operating systems that allow me >> to run several things at once like this: >> >> Compile & >> Analyze & >> wait >> >> If you must split it into multiple jobs, it is possible and even >> desirable if it allows you to get faster feedback. The only thing is, you >> cannot send the results upstream. If you have to have a single job where >> everything is available, both build artifacts and test results, you need to >> make a new job downstream that collects them both. >> >> There used to be this option to aggregate test results, which kind of >> does what you want but I never got it to work. Maybe that option is not >> compatible with multiconfiguration jobs which in use a lot. >> >> -- Sami >> >> intelchen <bihang.c...@gmail.com> kirjoitti 16.3.2012 kello 18.03: >> >> Hi, >> It would take so much time to get results of these static code >> analysis tools. >> For example, it takes 12minutes to get findbugs result of our one >> component. And we have more than 20 components in our products. >> And aslo we would like to use checkstyles,pmd besides findbugs. >> So I break apart them into two stage jobs. The fist stage is about >> compliation. The second stage is about these tools. >> And these tools could run in parallel.Then we could get the results more >> quickly, and send the reports to developers in short time. >> Is it a bad or good practice in Jenkins? >> >> Brs, >> Bill >> >> On Friday, March 16, 2012 8:59:13 PM UTC+8, sti wrote: >>> >>> The most straightforward way is to run the findbug analysis in the same >>> job. Why does it need to be run in its own job? >>> >>> Jenkins jobs are not as flexible as subroutines in programming >>> languages. If you start using them as such, you will shoot yourself in the >>> foot. >>> >>> -- Sami >>> >>> intelchen <bihang.c...@gmail.com> kirjoitti 16.3.2012 kello 9.28: >>> >>> Sorry for a uncompleted mail. >>> And I would like to copy the findbug_result.xml back to the workspaces >>> of the first job. >>> I think there would be a way to do that is write some shell scripts and >>> copy this result back to the former job. >>> But is there any other solution or existed plug-ins for this requirement? >>> May I have your ideas? Thanks! >>> >>> On Friday, March 16, 2012 3:23:30 PM UTC+8, intelchen wrote: >>>> >>>> Hi all, >>>> There are two stage jobs for one java project. >>>> One is to do compilation job and create a runtime jar file >>>> after polling codes from SCM. >>>> Second one is to do findbug analysis job. It copy artifact(runtime jar >>>> file) from upstream using Copy Artifact Plugin. And there would be a >>>> findbug_result.xml generated after this job. >>>> >>>>
