I have never had a problem with Jenkins not capturing output. And AFAICS the the wiki page you refer to does not mention such a problem either.
Sure, if you want to use background processes in your job, you will want to make sure you do not exit before you have waited for them all or killed them off. If you cancel a job, Jenkins will try to kill your background processes but it may not be perfect, so do not trust it. (For more info, search for "Jenkins ProcessTreeKiller") -- Sami 2012/3/19 intelchen <bihang.c...@gmail.com>: > > 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. >>>> >
