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

Git polling shouldn't need a workspace on a slave.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      What happened:

      I have two slaves (1 & 2). I took slave 1 down for maintenance and a bunch of old, rarely updated, git builds kicked off. When I checked the git polling log, I saw a message (it's gone now, darn it) that said it was rebuilding to get workspace for git polling.

      A workspace shouldn't be needed.

      I'm unclear what git needs for this, but if you're tracking only a single branch (master) then you just need the HEAD and can compare the SHA1s.

      If it technically really really needs a git checkout, then I'd prefer if they were kept on an assigned host (the jenkins server in my case, master) instead of using the workspaces for this check. I'd want this for a couple reasons:

      • Slaves come and go. Rebuilding all my projects because a slave went down is unproductive.
      • Occasionally, I need to go into a slave and monkey with a workspace to troubleshoot a weird problem. I don't want that to impact polling.
      • It's a waste of space on the slaves. I'd rather control where the space is wasted.

      Ciao!

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            The 1.6.2 release of git-client-plugin fixed a bug in ls-remote polling for the command line git implementation. The bug would have manifest itself as having ls-remote based polling show that there were changes when there were no changes.

            Refer to https://github.com/jenkinsci/git-client-plugin/commit/e5e75d5a100905c0d5b332bbde3642e96ffe10a9 for more details on the bug.

            That fix does not change the behavior described by Owen Jacobson. Remote polling does not apply commit filtering, so if you're using inclusion or exclusion filters in your job definition, you can't use remote polling.

            Show
            markewaite Mark Waite added a comment - The 1.6.2 release of git-client-plugin fixed a bug in ls-remote polling for the command line git implementation. The bug would have manifest itself as having ls-remote based polling show that there were changes when there were no changes. Refer to https://github.com/jenkinsci/git-client-plugin/commit/e5e75d5a100905c0d5b332bbde3642e96ffe10a9 for more details on the bug. That fix does not change the behavior described by Owen Jacobson. Remote polling does not apply commit filtering, so if you're using inclusion or exclusion filters in your job definition, you can't use remote polling.
            Hide
            drdt Don Ross added a comment -

            Now that the default behavior of the plug-in is to use remote polling, does this mean we need to not use exclusion filters?

            Show
            drdt Don Ross added a comment - Now that the default behavior of the plug-in is to use remote polling, does this mean we need to not use exclusion filters?
            Hide
            markewaite Mark Waite added a comment - - edited

            Don Ross you may continue to use exclusion filters and inclusion filters, but jobs which use them must be configured to "Force polling using workspace".

            Effectively, you're providing the compatibility with past behavior by forcing polling to use the workspace. Had you enabled fast remote polling with inclusion or exclusion filtering with git plugin releases prior to 2.0, you would have seen the same types of problems as exist today. The remote polling technique does not receive enough information to evaluate inclusion or exclusion filters.

            Show
            markewaite Mark Waite added a comment - - edited Don Ross you may continue to use exclusion filters and inclusion filters, but jobs which use them must be configured to "Force polling using workspace". Effectively, you're providing the compatibility with past behavior by forcing polling to use the workspace. Had you enabled fast remote polling with inclusion or exclusion filtering with git plugin releases prior to 2.0, you would have seen the same types of problems as exist today. The remote polling technique does not receive enough information to evaluate inclusion or exclusion filters.
            Hide
            drdt Don Ross added a comment -

            Thanks, Mark. I actually never got exclusions to work in prior versions, so I wanted to try them out now I upgraded.

            I am having trouble getting forced workspace polling to work at any rate; see my comments on https://issues.jenkins-ci.org/browse/JENKINS-20427.

            Show
            drdt Don Ross added a comment - Thanks, Mark. I actually never got exclusions to work in prior versions, so I wanted to try them out now I upgraded. I am having trouble getting forced workspace polling to work at any rate; see my comments on https://issues.jenkins-ci.org/browse/JENKINS-20427 .
            Hide
            markewaite Mark Waite added a comment -

            As described in the bug report, this is resolved. The git plugin does not require a workspace for polling, and the default (as of git plugin 2.0) is to not use a workspace for polling.

            The problems described by Owen Jacobson (and others) still exist for the somewhat more advanced use cases like excluding users, excluding files, and including files, but the basic issue reported by the bug is fixed.

            Show
            markewaite Mark Waite added a comment - As described in the bug report, this is resolved. The git plugin does not require a workspace for polling, and the default (as of git plugin 2.0) is to not use a workspace for polling. The problems described by Owen Jacobson (and others) still exist for the somewhat more advanced use cases like excluding users, excluding files, and including files, but the basic issue reported by the bug is fixed.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                docwhat Christian Höltje
              • Votes:
                22 Vote for this issue
                Watchers:
                27 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: