• Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • pipeline

      So that the properties step can be used to define, for example, a daily build schedule for some or all branch projects.

          [JENKINS-34005] Make WorkflowJob.triggers into a JobProperty

          Greg Smith added a comment -

          Mentioning in this enhancement request that this one would be important for those people who are not allowed to setup github hooks:

          In my project, we are not allowed any incoming hooks (long story, not negotiable) – so for us it is important to be able to configure a git polling interval for projects in a multi-branch configuration.

          As a firm example: We do a full scan of our github projects for new projects with Jenkinsfiles twice a day, but would like to configure those jobs to start polling github for changes every 15 minutes. This would allow the full scan to occur just once a day, but the job to be configured to poll and build on any changes in those projects more frequently.

          As I read and understand this, polling triggers would also be part of the configured job properties – just wanted to mention this specific use case.

          Greg Smith added a comment - Mentioning in this enhancement request that this one would be important for those people who are not allowed to setup github hooks: In my project, we are not allowed any incoming hooks (long story, not negotiable) – so for us it is important to be able to configure a git polling interval for projects in a multi-branch configuration. As a firm example: We do a full scan of our github projects for new projects with Jenkinsfiles twice a day, but would like to configure those jobs to start polling github for changes every 15 minutes. This would allow the full scan to occur just once a day, but the job to be configured to poll and build on any changes in those projects more frequently. As I read and understand this, polling triggers would also be part of the configured job properties – just wanted to mention this specific use case.

          Dan Jasek added a comment - - edited

          I implemented a solution to this, for the reason Greg describes.
          This is the step: https://gist.github.com/oillio/14cb6621877ecfb3a1d711e0f31ace90

          It is not the same solution as you describe. It is a new step which allows setting the scmTrigger for the job, instead of rewriting the job to use JobProperty for the triggers.

          If this is an acceptable fix, I would be happy to flesh this out and generalize it to other triggers, and submit it as a pull request.

          Dan Jasek added a comment - - edited I implemented a solution to this, for the reason Greg describes. This is the step: https://gist.github.com/oillio/14cb6621877ecfb3a1d711e0f31ace90 It is not the same solution as you describe. It is a new step which allows setting the scmTrigger for the job, instead of rewriting the job to use JobProperty for the triggers. If this is an acceptable fix, I would be happy to flesh this out and generalize it to other triggers, and submit it as a pull request.

          Jesse Glick added a comment -

          for us it is important to be able to configure a git polling interval for projects in a multi-branch configuration

          This functionality already exists, as a setting on the multibranch project (Periodically if not otherwise run trigger). You do not need a per-job trigger: branch indexing covers both checking for new/deleted branches, and checking for new heads on existing branches.

          This RFE is for other triggers (such as unconditional TimerTrigger), as well as perhaps a placeholder to countermand the suppression options from JENKINS-32396.

          Jesse Glick added a comment - for us it is important to be able to configure a git polling interval for projects in a multi-branch configuration This functionality already exists, as a setting on the multibranch project ( Periodically if not otherwise run trigger). You do not need a per-job trigger: branch indexing covers both checking for new/deleted branches, and checking for new heads on existing branches. This RFE is for other triggers (such as unconditional TimerTrigger ), as well as perhaps a placeholder to countermand the suppression options from JENKINS-32396 .

          Andrew Bayer added a comment -

          jglick - some initial questions on this... Are we talking about populating/mirroring the triggers field from a JobProperty or straight-up replacing the existing triggers field with a JobProperty and instantiating the pertinent Trigger instances on the fly? I kinda assume the former - particularly because we still want the traditional triggers UX on non-multibranch WorkflowJob...

          Andrew Bayer added a comment - jglick - some initial questions on this... Are we talking about populating/mirroring the triggers field from a JobProperty or straight-up replacing the existing triggers field with a JobProperty and instantiating the pertinent Trigger instances on the fly? I kinda assume the former - particularly because we still want the traditional triggers UX on non-multibranch WorkflowJob ...

          Jesse Glick added a comment -

          I was assuming we would fully replace triggers with a JobProperty.

          Jesse Glick added a comment - I was assuming we would fully replace triggers with a JobProperty .

          Andrew Bayer added a comment -

          So get rid of the AbstractProject-style API for triggers?

          Andrew Bayer added a comment - So get rid of the AbstractProject -style API for triggers?

          Andrew Bayer added a comment -

          ...which would break a lot of things, since ParmeterizedJobMixIn.ParameterizedJob expects Map<TriggerDescriptor,Trigger<?>> getTriggers()...

          Andrew Bayer added a comment - ...which would break a lot of things, since ParmeterizedJobMixIn.ParameterizedJob expects Map<TriggerDescriptor,Trigger<?>> getTriggers() ...

          Andrew Bayer added a comment -

          and on top of that, I'm not a huge fan of the idea of having to rework how triggers work for non-multibranch WorkflowJob, especially in the UI.

          Andrew Bayer added a comment - and on top of that, I'm not a huge fan of the idea of having to rework how triggers work for non-multibranch WorkflowJob , especially in the UI.

          Jesse Glick added a comment -

          Of course getTriggers would need to be made to look up the property.

          Jesse Glick added a comment - Of course getTriggers would need to be made to look up the property.

          Andrew Bayer added a comment -

          Again, I don't like the idea of breaking existing triggers on non-Multibranch WorkflowJob.

          Andrew Bayer added a comment - Again, I don't like the idea of breaking existing triggers on non-Multibranch WorkflowJob .

          Jesse Glick added a comment -

          What concretely would be “broken”? Of course you need to migrate any existing triggers field to the new format, as was done for prior conversions of fields to JobProperty, such as Job.logRotator.

          If you are not comfortable doing this fix, just do not assign to yourself; I have plenty of other stuff you can pick up.

          Jesse Glick added a comment - What concretely would be “broken”? Of course you need to migrate any existing triggers field to the new format, as was done for prior conversions of fields to JobProperty , such as Job.logRotator . If you are not comfortable doing this fix, just do not assign to yourself; I have plenty of other stuff you can pick up.

          Andrew Bayer added a comment -

          I guess a lot of my concern is the UI on non-Multibranch WorkflowJob - do we need a new UI approach for all the triggers-as-JobProperty or do things just magically work?

          Andrew Bayer added a comment - I guess a lot of my concern is the UI on non-Multibranch WorkflowJob - do we need a new UI approach for all the triggers-as- JobProperty or do things just magically work?

          Jesse Glick added a comment -

          Need to have a JobProperty implementing ReconfigurableDescribable whose configuration fragment picks up most of config-trigger.jelly, except the BuildAuthorizationToken config which should be moved into WorkflowJob/configure-entries.jelly in place of <p:config-trigger/>. The Descriptor should call Trigger.for_ to define the descriptors; otherwise f:descriptorList can use plain old field. reconfigure should call stop & start. getTriggers and addTrigger and getActions and getSCMTrigger need to be retrofitted. readResolve or similar should check for the old triggers field.

          Jesse Glick added a comment - Need to have a JobProperty implementing ReconfigurableDescribable whose configuration fragment picks up most of config-trigger.jelly , except the BuildAuthorizationToken config which should be moved into WorkflowJob/configure-entries.jelly in place of <p:config-trigger/> . The Descriptor should call Trigger.for_ to define the descriptors ; otherwise f:descriptorList can use plain old field . reconfigure should call stop & start . getTriggers and addTrigger and getActions and getSCMTrigger need to be retrofitted. readResolve or similar should check for the old triggers field.

          Andrew Bayer added a comment -

          Would the JobProperty contain a DescribableList of TriggerDescriptor/Trigger?

          Andrew Bayer added a comment - Would the JobProperty contain a DescribableList of TriggerDescriptor / Trigger ?

          Andrew Bayer added a comment -

          I ask because it seems a little silly to try to create some way of translating each Trigger into some non-Trigger format we can store in the JobProperty...

          Andrew Bayer added a comment - I ask because it seems a little silly to try to create some way of translating each Trigger into some non- Trigger format we can store in the JobProperty ...

          Andrew Bayer added a comment -

          Also, turns out JobProperty already implements ReconfigurableDescribable so I am not clear on what to do at the lower level now. Hrm.

          Andrew Bayer added a comment - Also, turns out JobProperty already implements ReconfigurableDescribable so I am not clear on what to do at the lower level now. Hrm.

          Jesse Glick added a comment -

          Use List<Trigger>.

          Jesse Glick added a comment - Use List<Trigger> .

          Andrew Bayer added a comment -

          Got my head straight on this and am moving forward. =)

          Andrew Bayer added a comment - Got my head straight on this and am moving forward. =)

          Andrew Bayer added a comment -

          Andrew Bayer added a comment - Initial PR work up at https://github.com/jenkinsci/workflow-job-plugin/pull/9

          Andrew Bayer added a comment -

          PR is basically functional now with decent testing, I think. Need to add a properties step test in workflow-multibranch still, and will need review, but I think we're most of the way there.

          Andrew Bayer added a comment - PR is basically functional now with decent testing, I think. Need to add a properties step test in workflow-multibranch still, and will need review, but I think we're most of the way there.

          Andrew Bayer added a comment -

          Multibranch test-related PR up as well. Snapshot deployed to support that.

          Andrew Bayer added a comment - Multibranch test-related PR up as well. Snapshot deployed to support that.

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          src/test/java/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStepTest.java
          http://jenkins-ci.org/commit/workflow-multibranch-plugin/25b46d278c43817556fe8492ad811418d51fa66e
          Log:
          JENKINS-34005 Add test for PipelineTriggersJobProperty.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/test/java/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStepTest.java http://jenkins-ci.org/commit/workflow-multibranch-plugin/25b46d278c43817556fe8492ad811418d51fa66e Log: JENKINS-34005 Add test for PipelineTriggersJobProperty.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          pom.xml
          src/test/java/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStepTest.java
          http://jenkins-ci.org/commit/workflow-multibranch-plugin/96993738c5fcead1076e613d5f2b5a34e6f3d466
          Log:
          Merge pull request #20 from abayer/jenkins-34005

          JENKINS-34005 - update tests for PipelineTriggersJobProperty

          Compare: https://github.com/jenkinsci/workflow-multibranch-plugin/compare/66ef6fa432d6...96993738c5fc

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: pom.xml src/test/java/org/jenkinsci/plugins/workflow/multibranch/JobPropertyStepTest.java http://jenkins-ci.org/commit/workflow-multibranch-plugin/96993738c5fcead1076e613d5f2b5a34e6f3d466 Log: Merge pull request #20 from abayer/jenkins-34005 JENKINS-34005 - update tests for PipelineTriggersJobProperty Compare: https://github.com/jenkinsci/workflow-multibranch-plugin/compare/66ef6fa432d6...96993738c5fc

            abayer Andrew Bayer
            jglick Jesse Glick
            Votes:
            10 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: