As a step towards JENKINS-32018, we could rather permit SCMTrigger but amend WorkflowJob.poll to ignore polling on any SCM which came from a branch project (i.e., scm argument to checkout rather than something else).

Disabling polling from properties means that it cannot be used in job configuration if any other properties are set. https://issues.jenkins-ci.org/browse/JENKINS-41146

Note that TimerTrigger (cron symbol) is occasionally desirable and unproblematic. For example, someone wants their master branch built every night, even if there are no recorded commits.

amend WorkflowJob.poll to ignore polling on any SCM which came from a branch project

I think this is really the correct behavior, rather than disabling polling altogether. The poll method gets a log handle so it can print a message about why it is ignoring polling on this SCM.

What I am not sure about is how to implement this. SCMVar just gets to pass back an SCM, of some plugin-provided type, and SCMStep does not have any particular way of knowing where it came from. You can easily find the SCMRevisionAction indicating that a branch source was active on this build, but the old API SCMListener.onCheckout just gets a SCMRevisionState, which is what is stored for future use from WorkflowJob.poll, and there is no API for correlating an SCMRevisionState with an SCMRevision: these capture essentially similar information but they are not interconvertible. Perhaps scm-api could be amended so that SCMRevision could check whether it was the same as a given SCMRevisionState. Unfortunately even with such an API, there is no way the git plugin will soon support this, until JENKINS-19022 is implemented so that it actually uses SCMRevisionState as the API mandates.

If you know about it, the correct behavior could be implemented using (untested!)

properties([pipelineTriggers([pollSCM('@daily')])])
node {
  dir('main') {
    // do not use SCMTrigger here, use branch indexing
    checkout scm: scm, poll: false
  }
  dir('other') {
    checkout([$class: 'GitSCM', userRemoteConfigs: [[url: 'http://wherever/']]])
  }
}

jglick: I am trying to get github/repoA/Jenkinsfile to use github/repoB.  The sample code that you provided works (polling, on a schedule).  Is it possible to get it to work on-push for rebuild of repoA when repoB is pushed?

When I use pollSCM("# on push"), nothing happens (either on push or at any later point).  I am guessing that the $Jenkins/github-webhook is not triggering the immediate pollSCM?

If I use githubPush() trigger, it double-triggers the main-repo (sometimes the builds are coalesced, sometimes not if concurrent builds are allowed); but I think this ticket implies that the githubPush() trigger should not be used in org/repo/branch jobs.

Alternately, I suppose I could add upstream-downstream relationships, but I have been trying to keep the triggers based on SCM vs jobs.

Note though that my Jenkins is at 2.60.1, and GitHub Branch Source 2.0.7 (a few months old), so maybe I should try upgrading, but it is probably my expectation that is wrong (user error, not a bug).

So, got it working.  On (enterprise) github, installed the "Jenkins (git plugin)" integration service which started calling the git-hook.

What is the recommenations for those who use webhooks and branch indexing?

We expirencing allot of duplicated builds...

Disabling branch indexing will cause new branches not to get indexed and built

Disabling webhooks will break a build per push bond we need...