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

Multiple triggers not working. Only first trigger works.

    Details

    • Similar Issues:

      Description

      We're using version 2.3 of this plugin.

      We have two triggers for our project, stable and unstable. Both trigger the same project but with a different variable value. See screenshot.

      When our build is unstable (and we have the unstable trigger in first place) the downstream project is triggered and it works fine. But when our build is stable no project is triggered.

      When we put stable on first place and unstable second. The same thing occurs. Stable triggers the downstream project and unstable not.

      I hope you can solve this for us.

      Kind regards,

      Evert-Jan

        Attachments

          Activity

          Hide
          mindless Alan Harder added a comment -

          Hm, this occurs because the DependencyGraph that Hudson maintains originally had no logic associated with the connections (a downstream job would always trigger). Thus, it has logic ignore dependencies connecting 2 projects that are already connected. However, here we connect the same 2 projects with dependencies using both different logic for when to trigger, and how to trigger (parameters).
          I tried the quick-fix in hudson core of simply removing the duplicate check.. this seems to work (my "unstable" trigger ran), although on the project page I now see the downstream project listed twice. The other question here is: if we allow multiple connections between projects A and B, should we allow B to be triggered more than once if the "should-trigger?" logic for more than one dependency DOES pass? My initial thought here is that we can allow it, and let the Queue deal with this (I think it'll already reject a complete duplicate, and allow the same project more than once if the parameters are different.. although, not sure what happens here if the job allows concurrent builds).

          Show
          mindless Alan Harder added a comment - Hm, this occurs because the DependencyGraph that Hudson maintains originally had no logic associated with the connections (a downstream job would always trigger). Thus, it has logic ignore dependencies connecting 2 projects that are already connected. However, here we connect the same 2 projects with dependencies using both different logic for when to trigger, and how to trigger (parameters). I tried the quick-fix in hudson core of simply removing the duplicate check.. this seems to work (my "unstable" trigger ran), although on the project page I now see the downstream project listed twice. The other question here is: if we allow multiple connections between projects A and B, should we allow B to be triggered more than once if the "should-trigger?" logic for more than one dependency DOES pass? My initial thought here is that we can allow it, and let the Queue deal with this (I think it'll already reject a complete duplicate, and allow the same project more than once if the parameters are different.. although, not sure what happens here if the job allows concurrent builds).
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/src/main/java/hudson/model/DependencyGraph.java
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/31934
          Log:
          [FIXED JENKINS-5708] collect multiple dependencies between same 2 projects into
          a DependencyGroup container; container checks each collected dependency and
          returns when the first one returns true for shouldTriggerBuild.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/java/hudson/model/DependencyGraph.java trunk/www/changelog.html http://jenkins-ci.org/commit/31934 Log: [FIXED JENKINS-5708] collect multiple dependencies between same 2 projects into a DependencyGroup container; container checks each collected dependency and returns when the first one returns true for shouldTriggerBuild.
          Hide
          mindless Alan Harder added a comment -

          note this is a fix in Hudson core.. you don't need a new parameterized-trigger plugin, just upgrade to Hudson 1.363 or higher when it comes out.

          Show
          mindless Alan Harder added a comment - note this is a fix in Hudson core.. you don't need a new parameterized-trigger plugin, just upgrade to Hudson 1.363 or higher when it comes out.
          Hide
          mindless Alan Harder added a comment -

          (and with regards to my self-debate above.. this only triggers the downstream project once.. stops looking at other dependencies after one triggers the job)

          Show
          mindless Alan Harder added a comment - (and with regards to my self-debate above.. this only triggers the downstream project once.. stops looking at other dependencies after one triggers the job)

            People

            • Assignee:
              mindless Alan Harder
              Reporter:
              ejschuiteman ejschuiteman
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: