Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            schamp schamp added a comment -

            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.

            Show
            schamp schamp added a comment - 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.
            Hide
            gcummings Geoff Cummings added a comment - - edited

            I have had a go at adding filtering based on Build result, this will also allow you to filter out jobs which have not completed yet.
            I am new at this so all feedback welcome!!

            https://github.com/jenkinsci/jenkins/pull/738

            thanks
            Geoff

            Show
            gcummings Geoff Cummings added a comment - - edited I have had a go at adding filtering based on Build result, this will also allow you to filter out jobs which have not completed yet. I am new at this so all feedback welcome!! https://github.com/jenkinsci/jenkins/pull/738 thanks Geoff
            Hide
            jglick Jesse Glick added a comment -

            I think this is the same as JENKINS-7280, right?

            Show
            jglick Jesse Glick added a comment - I think this is the same as JENKINS-7280 , right?
            Hide
            gcummings Geoff Cummings added a comment -

            Yes, I think it is the same as JENKINS-7280

            > "works just like the existing "Run Parameter", but is filtered to only include builds that have finished and didn't fail"

            Show
            gcummings Geoff Cummings added a comment - Yes, I think it is the same as JENKINS-7280 > "works just like the existing "Run Parameter", but is filtered to only include builds that have finished and didn't fail"
            Hide
            ioannis Ioannis Moutsatsos added a comment - - edited

            Take a look for an alternative approach that supports a 'smart run style parameter' generated by a groovy script. The script, getBuildByNumber_scriptlet.groovy, is accessible from github at: https://github.com/imoutsatsos/jenkins-scriptlets

            I had a similar requirement, that also included getting a list of builds within a range of build numbers. Was posted as JENKINS-21243 but it is still outstanding. Hope this helps!

            Show
            ioannis Ioannis Moutsatsos added a comment - - edited Take a look for an alternative approach that supports a 'smart run style parameter' generated by a groovy script. The script, getBuildByNumber_scriptlet.groovy, is accessible from github at: https://github.com/imoutsatsos/jenkins-scriptlets I had a similar requirement, that also included getting a list of builds within a range of build numbers. Was posted as JENKINS-21243 but it is still outstanding. Hope this helps!

              People

              • Assignee:
                gcummings Geoff Cummings
                Reporter:
                ltrider ltrider
              • Votes:
                2 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: