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

Git plugin polling requires workspace even when "Force polling using workspace" is NOT defined

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins server v2.89.2
      Git plugin v3.8.0
      Git client plugin v2.7.1
      GitHub plugin v1.29.0
      GitHub API plugin v1.90
      GitHub Pull Request Builder v1.40.0
    • Similar Issues:

      Description

      I have two jobs defined that each build a specific branch (master and 0.0.1) within a github enterprise repo that I'm using for testing.   Build triggering is defined on each one to build when a push is done, and I have configured my github repo with the required webhook.   The webhook is in fact working as the jenkins server logs a message when the webhook POST is received.

      The problem is that when I push a commit to either branch (0.0.1 or master), then BOTH jobs are kicked off.   When looking at the polling log info for each of the jobs that are kicked off I see something like this:

      ------------------------------------------------

      Started on Apr 9, 2018 4:24:11 PM Started by event from 9.209.1.17 ⇒

      https://wh-fhir-server-jenkins.swg-devops.com:8443/github-webhook/

      on Mon Apr 09 16:24:11 UTC 2018 Workspace is offline. Scheduling a new build to get a workspace. (nonexisting_workspace) Done. Took 0 ms Changes found

      ------------------------------------------------

      This looks like the git plugin is performing the non-remote polling which requires a workspace, rather than remote polling which would not.  I have not configured the "Force polling using workspace" additional behavior for either of these jobs.

      One additional detail...  Build agents are allocated from a docker swarm using a docker container/image which is wiped clean after each build is finished, so each new build effectively gets assigned to a "clean" agent.   For this reason, we cannot use the workspace-based polling and must use the remote polling.

      How can I ensure that remote polling is performed by default?   Is there a way to enable additional logging on the Jenkins server to try to determine why the default remote polling is apparently not performed or is perhaps encountering an error?

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          There are cases where the plugin decides that it can't use remote polling and must poll with the workspace. For example, workspace based polling is required if a Freestyle job definition includes any of the following:

          • wildcard branch names (other than '*/branchName') (see getSingleBranch in git-client-plugin)
          • multiple branches to built by a single job (see getSingleBranch in git-client-plugin)
          • multiple repositories defined for a single job and the repository name is not the initial substring of the branch name (see getSingleBranch in git-client-plugin)
          • an exclude message or path definition
          • an include region definition
          • an excluded user definition
          • using "author in changelog" instead of the default
          • computing the change log to a branch instead of the default
          • forcing polling using workspace

          Do any of those conditions apply to your job definition?

          Show
          markewaite Mark Waite added a comment - There are cases where the plugin decides that it can't use remote polling and must poll with the workspace. For example, workspace based polling is required if a Freestyle job definition includes any of the following: wildcard branch names (other than '*/branchName') (see getSingleBranch in git-client-plugin) multiple branches to built by a single job (see getSingleBranch in git-client-plugin) multiple repositories defined for a single job and the repository name is not the initial substring of the branch name (see getSingleBranch in git-client-plugin) an exclude message or path definition an include region definition an excluded user definition using "author in changelog" instead of the default computing the change log to a branch instead of the default forcing polling using workspace Do any of those conditions apply to your job definition?
          Hide
          padamstx Phil Adams added a comment -

          Mark,

          Thank you for the quick response.   It turns out that I do in fact use the "Use the commit author in changelog" additional behavior in both jobs.   I removed that from both job definitions and it now looks like things are working correctly.   A push to one branch results in only that branch's job from being kicked off, and I've verified that by observing the server log messages as well.

          Thanks again!

          Show
          padamstx Phil Adams added a comment - Mark, Thank you for the quick response.   It turns out that I do in fact use the "Use the commit author in changelog" additional behavior in both jobs.   I removed that from both job definitions and it now looks like things are working correctly.   A push to one branch results in only that branch's job from being kicked off, and I've verified that by observing the server log messages as well. Thanks again!
          Hide
          padamstx Phil Adams added a comment -

          I guess we can close this out as "works as designed" but it might be helpful for others in my situation if the git plugin documentation was a bit clearer on when the remote polling option can be used and when the plugin has to revert to local/workspace polling.

          Show
          padamstx Phil Adams added a comment - I guess we can close this out as "works as designed" but it might be helpful for others in my situation if the git plugin documentation was a bit clearer on when the remote polling option can be used and when the plugin has to revert to local/workspace polling.
          Hide
          markewaite Mark Waite added a comment -

          Included in git plugin 3.9.0 released 12 May 2018

          Show
          markewaite Mark Waite added a comment - Included in git plugin 3.9.0 released 12 May 2018

            People

            • Assignee:
              Unassigned
              Reporter:
              padamstx Phil Adams
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: