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

trigger parameterized builds only triggers the first instance of a project

      Configure Job A to trigger Job B twice, with differing parameters. Only the first instance of Job B will be triggered.

      Eg.

      Job A has two triggers:
      Job B, predefined parameter BRANCH=master
      Job B, predefined parameter BRANCH=testbranch

      When Job A finishes building, it will trigger Job B with BRANCH=master, but it will not trigger it a second time with BRANCH=testbranch, as required.

          [JENKINS-8985] trigger parameterized builds only triggers the first instance of a project

          evilchili created issue -
          Maik Richey made changes -
          Link New: This issue is duplicated by JENKINS-9333 [ JENKINS-9333 ]

          Maik Richey added a comment - - edited

          Seems that people other then me also stumbling across this issue. So it's probably worth taking a look at...

          Anyone?

          Maik Richey added a comment - - edited Seems that people other then me also stumbling across this issue. So it's probably worth taking a look at... Anyone?

          Maik Richey added a comment -

          Builds are scheduled/triggered in hudson.tasks.BuildTrigger.execute() in case Dependency dep.shouldTriggerBuild() returns true. When dep is an instance of hudson.model.DependencyGraph.DependencyGroup this is a problem because loop is left at once if shouldTriggerBuild() is true instead of checking the rest of the group as well. That's why only the first build is triggered. See hudson.model.DependencyGraph.DependencyGroup.shouldTriggerBuild(AbstractBuild, TaskListener, List<Action>.

          Can someone please confirm?

          Maik Richey added a comment - Builds are scheduled/triggered in hudson.tasks.BuildTrigger.execute() in case Dependency dep.shouldTriggerBuild() returns true. When dep is an instance of hudson.model.DependencyGraph.DependencyGroup this is a problem because loop is left at once if shouldTriggerBuild() is true instead of checking the rest of the group as well. That's why only the first build is triggered. See hudson.model.DependencyGraph.DependencyGroup.shouldTriggerBuild(AbstractBuild, TaskListener, List<Action> . Can someone please confirm?

          Maik Richey added a comment -

          Added component core because this issue may be an issue in the core not the plugin.

          Maik Richey added a comment - Added component core because this issue may be an issue in the core not the plugin.
          Maik Richey made changes -
          Component/s New: core [ 15593 ]
          Andrew Bayer made changes -
          Assignee Original: huybrechts [ huybrechts ] New: Andrew Bayer [ abayer ]

          Andrew Bayer added a comment -

          Yup, this is both core and parameterized-trigger - I'm pushing fixes to both, but while we can release parameterized-trigger ASAP, the fix won't actually work until Jenkins core 1.414.

          Andrew Bayer added a comment - Yup, this is both core and parameterized-trigger - I'm pushing fixes to both, but while we can release parameterized-trigger ASAP, the fix won't actually work until Jenkins core 1.414.

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          changelog.html
          core/src/main/java/hudson/tasks/BuildTrigger.java
          http://jenkins-ci.org/commit/jenkins/e6d6c925643517d683dcd1e0b6fb3b463a9a7401
          Log:
          JENKINS-8985 BuildTrigger modification to handle DependencyGroups.

          Pull individual Dependencys out of DependencyGroups we see in
          BuildTrigger.execute and make sure to actually kick those builds off
          as well, so that we can have two different dependencies (say, for
          different parameters) from one upstream project to a single downstream
          project.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: changelog.html core/src/main/java/hudson/tasks/BuildTrigger.java http://jenkins-ci.org/commit/jenkins/e6d6c925643517d683dcd1e0b6fb3b463a9a7401 Log: JENKINS-8985 BuildTrigger modification to handle DependencyGroups. Pull individual Dependencys out of DependencyGroups we see in BuildTrigger.execute and make sure to actually kick those builds off as well, so that we can have two different dependencies (say, for different parameters) from one upstream project to a single downstream project.

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          changelog.html
          core/src/main/java/hudson/model/DependencyGraph.java
          core/src/main/java/hudson/tasks/BuildTrigger.java
          http://jenkins-ci.org/commit/jenkins/78c709e91329d4b4ba6f36f25a64412ade63c215
          Log:
          JENKINS-8985 BuildTrigger modification to handle DependencyGroups.

          Pull individual Dependencys out of DependencyGroups we see in
          BuildTrigger.execute and make sure to actually kick those builds off
          as well, so that we can have two different dependencies (say, for
          different parameters) from one upstream project to a single downstream
          project.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: changelog.html core/src/main/java/hudson/model/DependencyGraph.java core/src/main/java/hudson/tasks/BuildTrigger.java http://jenkins-ci.org/commit/jenkins/78c709e91329d4b4ba6f36f25a64412ade63c215 Log: JENKINS-8985 BuildTrigger modification to handle DependencyGroups. Pull individual Dependencys out of DependencyGroups we see in BuildTrigger.execute and make sure to actually kick those builds off as well, so that we can have two different dependencies (say, for different parameters) from one upstream project to a single downstream project.

            abayer Andrew Bayer
            evilchili evilchili
            Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: