• 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

          Jesse Glick created issue -
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-30519 [ JENKINS-30519 ]
          Jesse Glick made changes -
          Link New: This issue is duplicated by JENKINS-33378 [ JENKINS-33378 ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-32396 [ JENKINS-32396 ]
          Jesse Glick made changes -
          Epic Link New: JENKINS-35386 [ 171179 ]

          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 .
          Jesse Glick made changes -
          Link New: This issue is blocking JENKINS-34725 [ JENKINS-34725 ]

          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 ...

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

              Created:
              Updated:
              Resolved: