-
Improvement
-
Resolution: Duplicate
-
Major
-
None
We have a large matrix of tests that we'd like to configure to run nightly. We have had good success running a smaller matrix of tests directly after a build by parameterizing the test job with "Run Parameter" and having build job trigger test job. In that context I can specify that I only want tests triggered on a good build. It is more difficult for the nightly. We set it up with the same "Run Parameter", except now build doesn't trigger it, but we use @midnight timer instead. That sort-of works. The issue is that the "Run Parameter" includes the build currently running and bad builds too. Odds are very good that tests will fail because they catch the build in progress with needed artifacts not available.
We've considered using lastSuccessfulBuild URL instead of the "Run Parameter" to download build artifacts, but that doesn't really work for us. Since our test job is a matrix of jobs, different cells in the matrix could potentially run against a different build. That's not good. We'd also like the ability to invoke the nightly tests manually against a specific build.
In short, what we'd really like is a "Good Run Parameter" that works just like the existing "Run Parameter", but is filtered to only include builds that have finished and didn't fail.
- duplicates
-
JENKINS-7280 run parameters show builds that have not completed or have failed / unstable
-
- Resolved
-
- is related to
-
JENKINS-9209 Condition to demand a parameter to exist
-
- Resolved
-
We have a similar need. We were thinking that a more general solution would be to make the parameterized trigger conditional on some configurable test, for example, if "BUILD_STATUS=stable" or "BUILD_TYPE=incremental". We have a large battery of tests we want to run for full builds, but not incremental builds. Conditionally triggering a downstream job (based on more than just the build status) would allow a lot more flexibility in configuring reusable job pipelines, especially when (like ours) the jobs make reference to a large number of parameters to define their behavior.
Our short-term workaround is to add a scripted check for the condition we want, and cause a failure if it occurs, and then trigger a build based on that failure, but we'd prefer to leave the "failure" condition refer to actual failures, instead of this hack.