Community
Participate
Working Groups
I see a few issues, wanted to capture them there. At the root, it may simply take too long to run "long running" tests with every I-build. But, worse, there's two types of "jobs" that run: a) the actual tests, b) a small, quick job that tells the "build machine" that a job is does and on the machine is a cron job that runs every 10 minutes to see if there are any new results to gather. (Sort of poor man's messaging queue). So, the problem is, when lots of tests are ran, and get queued up, a "collect job" can be "way back" in the queue, depriving committers from "seeing" the results for 5 or 10 hours or more, but not yet available, simply because the "collect trigger" job is still in the queue. For example Build Queue: ep-collectResults ep45I-perf-lin64-baseline ep-collectResults Running jobs: (Build Executor Status) Building ep45ILR-perf-lin64-baseline #6 <== from 12/8 8 AM build I think this is easy to fix. To define two "executors" but to also define one "performance lock" and each true "performance job" must aquire that one lock before being allowed to run. Fairly sure this would have the effect if letting "collectResults" jobs run when ever they are ready, but keep the performance jobs nice and orderly, running only one at a time. And, yes, have the "collect job" run during the performance test does risk "contaminating" the performance data, but each "collect job" executes in about 100 ms, so ... I don't think the effect will be two much. ;
On our current performance test machine, I fixed the issue with "collect Results" in bug 455639 ... simply have each job to push their own "results ready" file to "shared area" (since, the machine has access to it). But, that would not work if/when we also do the tests on Windows. Plus, I see a similar problem, just during a normal weekly "I build". The "long running" tests are still running when the nightly build finishes. And, one of it's "short running" performance tests gets "in the queue" before the last long running test job does, hence the I-build results are held up by a nightly build. Not good. The answer to both type of problem might be a plugin that allows setting and computing priorities of jobs in the queue. See https://wiki.jenkins-ci.org/display/JENKINS/Priority+Sorter+Plugin That plugin is "for Jenkins" ... but, often they run on either, or, there is a corresponding one for Hudson.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
