The Problem

We would very much like to stop using frequent polling and switch over to using SCM post-commit hooks to trigger our builds. However this is problematic in two situations.

Before I begin, let me say that in the below, I speak of parameterizing the repo URL, which is our situation but probably something of an edge case. However I believe the same problem applies to parameterizing the branch as well, which is the normal case.

The first is when we have a parameterized build and our SCM Repository Repo value is hence parameterized, e.g. Repository URL = "$GIT_REPO". The parameter has a default value, which is what $GIT_URL evaluates to for scheduled polling purposes. This evaluation does not take place however when evaluating all jobs to see which ones need to poll when commit notifications are received. The workaround is to create a wrapper job that is not parameterized and hence can respond to the commit notification and which then invokes the parameterized job. With hundreds of such jobs, creating hundreds more as wrappers is problematic on several fronts.

The second problem is even more pernicious. In the new workflow job types, SCM Polling is entirely dependent upon which repo(s)/branch(es) the job's last build evaluated. This causes several problems. 1) If you have not run the job once manually, then polling and commit hooks are effectively disabled. Worse, even when "enabled", in a parameterized build situation, rather than polling/listening-for-hooks with the job's default parameters, workflows use the last parameters with which they were run, whatever random, arbitrary, temporary repo/branch that might have been. That is very bad.

The Solution

To address these problems, I propose the following feature:

Under the "Poll SCM" Build Trigger, add an Advanced section that includes fields for specifying the SCM parameters to use for polling and hence processing post-commit hooks. In order to adequately support this solution for workflow jobs, likely ALL the SCM fields will need to be captured here, SCM type, credentials, executable, additional behaviors, etc. The values in this advanced section, when provided, would then be used as the basis for all polling and post-commit notification evaluations, overriding any other values.

Thoughts?