-
Improvement
-
Resolution: Duplicate
-
Minor
-
None
If I want to run five different test suites, each having their own test result patterns, on five different nodes, in parallel, how do I do that?
The abbreviated pipeline below all seems to work except for the collecting test results part, since when tests fail, the junit instruction is ignored (I guess since the previous step had a non-zero exit code).
When not using the new declarative pipeline format, I could potentially use try/catch/finally and shove the junit instruction in the finally block as seen here.
Current attempt:
pipeline {
agent label:'master'
environment {
GIT_COMMITTER_NAME = "jenkins"
GIT_COMMITTER_EMAIL = "jenkins@jenkins.io"
}
stages {
stage("Build") {
steps {
parallel (
"sweet" : {
node("has-docker") {
git 'ssh://git@stash.example.com/automation/sweet.git'
sh 'APP_NAME=sweet \
TEST_ENV=qa5 \
bin/ci'
junit '**/test-reports/*.xml'
}
},
"word" : {
node("has-docker") {
git 'ssh://git@stash.example.com/automation/word.git'
sh 'APP_NAME=word \
TEST_ENV=qa5 \
bin/ci'
junit '**/nosetests.xml'
}
}
)
}
}
}
post {
always {
deleteDir()
}
}
}
So in summary, the existing docs on parallel execution are pretty good, but they don't describe how to collect test results from parallel executions on different nodes.
- duplicates
-
JENKINS-41334 Support parallel execution of stages in Declarative
-
- Closed
-
[JENKINS-40699] Post-stage/build test results etc doesn't play well with parallel on multiple nodes
Huh, interesting point. Hadn't thought about that case. I'm gonna leave this open and rename it - this seems like a valid problem.
We do have the same problem.
Would have thought that the «post» declarative would be able to be set for each parallel task.
But it is only available in the top-level pipeline block and in each stage block.
Back to the «try/catch/finally» hack.
So this'll be addressed by JENKINS-41334, which adds nested parallel stage support.
ok, so my specific use case can be solved by doing this instead of the code above in the sh instruction:
bin/ci || trueis adding "or true" so it doesn't abort execution before collecting test results the "right" solution?