Currently hudson.plugins.parameterizedtrigger.BuildTriggerConfig and related classes is designed to assume that the downstream project is an AbstractProject, preventing it from triggering a WorkflowJob in schedule (see also perform, perform2, DescriptorImpl.doCheckProjects, etc.).

      This could probably be relaxed by just checking for a Job & Queue.Task from which you can schedule a job with a little difficulty (check ParameterizedJob.getQuietPeriod and Job.isBuildable); or perhaps SCMTriggerItem whose scheduleBuild2 is more convenient.

      Should work smoothly for TriggerBuilder. For BuildTrigger, can work to the extent that canDeclare is made to be false, so that the triggering is done explicitly rather than via DependencyDeclarer (and thus the DependencyGraph, which at least for now is restricted to AbstractProject).

          [JENKINS-26050] Workflow integration for Parameterized Trigger

          Jesse Glick created issue -
          ikedam made changes -
          Link New: This issue is related to JENKINS-26009 [ JENKINS-26009 ]

          ikedam added a comment -

          Problems happen when simply replaced AbstractProject to Job:

          • Job doesn't provide scheduleBuild2 (in BuildTriggerConfig#schedule)
          • Job doesn't provide getQueuePeriod (in BuildTriggerConfig#schedule)
          • Job doesn't provide findNearest (in BuildTriggerConfig.DescriptorImpl#doCheckProjects)
          • DependencyGraph works only for AbstractProject.

          ikedam added a comment - Problems happen when simply replaced AbstractProject to Job : Job doesn't provide scheduleBuild2 (in BuildTriggerConfig#schedule ) Job doesn't provide getQueuePeriod (in BuildTriggerConfig#schedule ) Job doesn't provide findNearest (in BuildTriggerConfig.DescriptorImpl#doCheckProjects ) DependencyGraph works only for AbstractProject .

          ikedam added a comment -

          What I cannot understand:

          • WorkflowJob doesn't inherit AbstractProject.
          • AbstractProject doesn't implements SCMTriggerItem.
            • SCMTriggerItem (since Jenkins 1.568) provides scheduleBuild2 and getQuietPeriod, and looks a good replacement for AbstractProject.
          • DependencyGraph works only for AbstractProject.
            • Does workflow-plugin provides alternate way to define dependencies between workflow projects?

          ikedam added a comment - What I cannot understand: WorkflowJob doesn't inherit AbstractProject . AbstractProject doesn't implements SCMTriggerItem . SCMTriggerItem (since Jenkins 1.568) provides scheduleBuild2 and getQuietPeriod , and looks a good replacement for AbstractProject . DependencyGraph works only for AbstractProject . Does workflow-plugin provides alternate way to define dependencies between workflow projects?

          Jesse Glick added a comment -

          Job doesn't provide scheduleBuild2

          Job doesn't provide getQueuePeriod [getQuietPeriod?]

          ParameterizedJobMixIn provides both. SCMTriggerItem is not appropriate here.

          Job doesn't provide findNearest

          This should really be deprecated, and callers directed to use the more general Items.findNearest.

          DependencyGraph works only for AbstractProject.

          True; until this core refactoring is done, this mode would simply not be supported for workflows. See the third paragraph of my original description.

          AbstractProject doesn't implements SCMTriggerItem

          It is implement by Project. At any rate, as above, do not pay attention to this interface here.

          Does workflow-plugin provides alternate way to define dependencies between workflow projects?

          Other than the fact that a workflow can build another and provide an UpstreamCause, no, there is no DependencyGraph support. Again, for TriggerBuilder (and one mode of BuildTrigger) this does not matter.

          Jesse Glick added a comment - Job doesn't provide scheduleBuild2 Job doesn't provide getQueuePeriod [getQuietPeriod?] ParameterizedJobMixIn provides both. SCMTriggerItem is not appropriate here. Job doesn't provide findNearest This should really be deprecated, and callers directed to use the more general Items.findNearest . DependencyGraph works only for AbstractProject. True; until this core refactoring is done, this mode would simply not be supported for workflows. See the third paragraph of my original description. AbstractProject doesn't implements SCMTriggerItem It is implement by Project . At any rate, as above, do not pay attention to this interface here. Does workflow-plugin provides alternate way to define dependencies between workflow projects? Other than the fact that a workflow can build another and provide an UpstreamCause , no, there is no DependencyGraph support. Again, for TriggerBuilder (and one mode of BuildTrigger ) this does not matter.

          Jesse Glick added a comment -

          Jesse Glick added a comment - https://github.com/jenkinsci/build-token-root-plugin/commit/e859e2f1cb51b203f8e13932f76ac0a69b2e75e5 may be helpful as an example of ParameterizedJobMixIn usage.
          Jesse Glick made changes -
          Summary Original: Workflow integration New: Workflow integration for Parameterized Trigger
          Jesse Glick made changes -
          Link New: This issue is duplicated by JENKINS-27965 [ JENKINS-27965 ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-28113 [ JENKINS-28113 ]

          Markus added a comment - - edited

          Any one that has a workaround for the lack of Workflow integration for Parameterized Trigger? The triggering can be solved, but I have problems passing parameters to a downstream Workflow without the Parameterized Trigger plugin. ("Who actually triggered me?")

          Edit: My workaround seems to be set up the downstream workflow job as a normal parametrized job. These parameters are available directly as variables. I'll then use the REST API and curl to trigger the "downstream" job with parameters.

          Markus added a comment - - edited Any one that has a workaround for the lack of Workflow integration for Parameterized Trigger? The triggering can be solved, but I have problems passing parameters to a downstream Workflow without the Parameterized Trigger plugin. ("Who actually triggered me?") Edit: My workaround seems to be set up the downstream workflow job as a normal parametrized job. These parameters are available directly as variables. I'll then use the REST API and curl to trigger the "downstream" job with parameters.

            svanoort Sam Van Oort
            jglick Jesse Glick
            Votes:
            15 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated:
              Resolved: