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.

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.

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

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

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

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

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.

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

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

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.

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?

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.

Would the JobProperty contain a DescribableList of TriggerDescriptor/Trigger?

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

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

Use List<Trigger>.

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

Initial PR work up at https://github.com/jenkinsci/workflow-job-plugin/pull/9

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.

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.

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