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

Make WorkflowJob.triggers into a JobProperty

    XMLWordPrintable

Details

    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

            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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            Would the JobProperty contain a DescribableList of TriggerDescriptor/Trigger?

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

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

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

            Use List<Trigger>.

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

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

            abayer Andrew Bayer added a comment - Got my head straight on this and am moving forward. =)
            abayer Andrew Bayer added a comment - Initial PR work up at https://github.com/jenkinsci/workflow-job-plugin/pull/9
            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.

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

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

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

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

            People

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

              Dates

                Created:
                Updated:
                Resolved: