Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17893

Add option to block parent build when using parameterized trigger as a post-build action

XMLWordPrintable

      I use parameterized trigger in matrix jobs to trigger a deploy after the job builds. But I only want to trigger the deploy job once for each job run, not once for every slave that the build runs on. To do that, it seems that I have to use the plugin as a post-build action, but then I can't block the parent job until the downstream job finishes. I would really like to be able to do that, AND have the parent job succeed/fail based on the downstream job result.

          [JENKINS-17893] Add option to block parent build when using parameterized trigger as a post-build action

          Owen Mehegan added a comment -

          I noticed you have made a lot of commits to this plugin recently - hoping you would be interested in looking at this

          Owen Mehegan added a comment - I noticed you have made a lot of commits to this plugin recently - hoping you would be interested in looking at this

          ikedam added a comment -

          I see your points.
          But Jenkins is not designed to decide build results by results of downstream builds, and I do not plan to add features out of that design of Jenkins.

          In that case, people seem to use Promoted Builds plugin (https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin).
          For build execution exclusion, you can use Throttle Concurrent Builds plugin (https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin) .
          Or, though I haven't ever used it, Multijob plugin may help you (https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin).

          Would you see whether above plugins can meet your requirements, and let me know what they cannot meet?

          ikedam added a comment - I see your points. But Jenkins is not designed to decide build results by results of downstream builds, and I do not plan to add features out of that design of Jenkins. In that case, people seem to use Promoted Builds plugin ( https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin ). For build execution exclusion, you can use Throttle Concurrent Builds plugin ( https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin ) . Or, though I haven't ever used it, Multijob plugin may help you ( https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin ). Would you see whether above plugins can meet your requirements, and let me know what they cannot meet?

          Owen Mehegan added a comment -

          OK, I understand what you're saying. Here is an alternative suggestion that would help me: can you add an option so that, when the plugin is used as a build step in a matrix build, it only runs once for the whole job, instead of once per axis of the matrix? That would still allow me to trigger the deploy job only once, and have the build job fail if the deploy job fails.

          Owen Mehegan added a comment - OK, I understand what you're saying. Here is an alternative suggestion that would help me: can you add an option so that, when the plugin is used as a build step in a matrix build, it only runs once for the whole job, instead of once per axis of the matrix? That would still allow me to trigger the deploy job only once, and have the build job fail if the deploy job fails.

          ikedam added a comment -

          Only aggregations of publishers can run for whole a matrix project.
          It sounds good to extend Any Build Step plugin to allow a build step run as a aggregation.

          ikedam added a comment - Only aggregations of publishers can run for whole a matrix project. It sounds good to extend Any Build Step plugin to allow a build step run as a aggregation.

          Owen Mehegan added a comment -

          I decided to start using the Build Flow plugin to orchestrate this behavior. I just create a build flow that orchestrates the build, deploy, and integration test run against the deploy environment. People can run the "flow" job and watch the whole process, and if something fails then the "flow" is marked as failed. I think this is cleaner.

          Owen Mehegan added a comment - I decided to start using the Build Flow plugin to orchestrate this behavior. I just create a build flow that orchestrates the build, deploy, and integration test run against the deploy environment. People can run the "flow" job and watch the whole process, and if something fails then the "flow" is marked as failed. I think this is cleaner.

            ikedam ikedam
            owenmehegan Owen Mehegan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: