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

Make WorkflowJob.triggers into a JobProperty

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

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

        Attachments

          Issue Links

            Activity

            jglick Jesse Glick created issue -
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Link This issue depends on JENKINS-30519 [ JENKINS-30519 ]
            jglick Jesse Glick made changes -
            Link This issue is duplicated by JENKINS-33378 [ JENKINS-33378 ]
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-32396 [ JENKINS-32396 ]
            jglick Jesse Glick made changes -
            Epic Link JENKINS-35386 [ 171179 ]
            Hide
            gregcovertsmith 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.

            Show
            gregcovertsmith 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.
            Hide
            danjasek 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.

            Show
            danjasek 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.
            Hide
            jglick 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.

            Show
            jglick 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 .
            jglick Jesse Glick made changes -
            Link This issue is blocking JENKINS-34725 [ JENKINS-34725 ]
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - Jesse Glick - 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 ...
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - I was assuming we would fully replace triggers with a JobProperty .
            Hide
            abayer Andrew Bayer added a comment -

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

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

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

            Show
            abayer Andrew Bayer added a comment - ...which would break a lot of things, since ParmeterizedJobMixIn.ParameterizedJob expects Map<TriggerDescriptor,Trigger<?>> getTriggers() ...
            Hide
            abayer 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.

            Show
            abayer 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.
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - Of course getTriggers would need to be made to look up the property.
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - Again, I don't like the idea of breaking existing triggers on non-Multibranch WorkflowJob .
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            abayer 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?

            Show
            abayer 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?
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            abayer Andrew Bayer added a comment -

            Would the JobProperty contain a DescribableList of TriggerDescriptor/Trigger?

            Show
            abayer Andrew Bayer added a comment - Would the JobProperty contain a DescribableList of TriggerDescriptor / Trigger ?
            Hide
            abayer 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...

            Show
            abayer 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 ...
            Hide
            abayer 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.

            Show
            abayer 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.
            Hide
            jglick Jesse Glick added a comment -

            Use List<Trigger>.

            Show
            jglick Jesse Glick added a comment - Use List<Trigger> .
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - Got my head straight on this and am moving forward. =)
            abayer Andrew Bayer made changes -
            Assignee Jesse Glick [ jglick ] Andrew Bayer [ abayer ]
            abayer Andrew Bayer made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Hide
            abayer Andrew Bayer added a comment -
            Show
            abayer Andrew Bayer added a comment - Initial PR work up at https://github.com/jenkinsci/workflow-job-plugin/pull/9
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "workflow-job-plugin PR #9 (Web Link)" [ 14625 ]
            Hide
            abayer 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.

            Show
            abayer 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.
            Hide
            abayer Andrew Bayer added a comment -

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

            Show
            abayer Andrew Bayer added a comment - Multibranch test-related PR up as well. Snapshot deployed to support that.
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "workflow-multibranch-plugin PR #20 (Web Link)" [ 14629 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 170021 ] JNJira + In-Review [ 185710 ]
            jglick Jesse Glick made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            gregcovertsmith Greg Smith made changes -
            Link This issue is related to JENKINS-37477 [ JENKINS-37477 ]
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-45067 [ JENKINS-45067 ]

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: