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

Permit specifying an SCM Configuration as an Advanced setting under SCM Polling Trigger

    Details

    • Similar Issues:

      Description

      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?

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          Not a goal for Workflow. You should never parameterize your SCM this way; polling cannot work if you. If what you were trying to accomplish is to handle multiple branches/forks of what is logically one repository, you should use the Workflow: Multibranch plugin (currently in beta). For freestyle-ish projects, you can use one of the other branch-api integrations.

          Show
          jglick Jesse Glick added a comment - Not a goal for Workflow. You should never parameterize your SCM this way; polling cannot work if you. If what you were trying to accomplish is to handle multiple branches/forks of what is logically one repository, you should use the Workflow: Multibranch plugin (currently in beta). For freestyle-ish projects, you can use one of the other branch-api integrations.

            People

            • Assignee:
              Unassigned
              Reporter:
              kbaltrinic Kenneth Baltrinic
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: