I suspect the answer here may be to run the child jobs in a build step, while the parent job waits, and then gravs the downstream jobs artifacts via url. The cli can be used for synchronous job runs, and with a newer jenkins you may even be able to use the SSH system to do it (saves grabbing a copy of that cli jar).
You can actually combine those synchronous runs with wgets in a shell script using the same facilities sti has mentioned: (java -jar jenkins-cli.jar $JENKINS_URL build compile_job && wget <artifact name>) & (java -jar jenkins-cli.jar $JENKINS_URL build analyze_job && wget <artifact name>) & wait I've generalized, and you'll want to look at the cli commands on your server (read https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI) for info on it. I also use a for pid in `jobs` style thing if I've many unix jobs on a shell I want to wait for - again, you'll want to familiarise yourself with the job handling syntax of your shell or build language for such things. On Friday, 16 March 2012 17:54:27 UTC, 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. >>> >>>
