Details
-
Improvement
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
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
- is related to
-
JENKINS-9596 SCM polling with GIT creates Spurious Builds with "No Changes"
-
- Open
-
-
-
- Closed
-
-
-
- Open
-
-
JENKINS-9067 Add "Only poll using master" option
-
- Resolved
-
Activity
Now that the default behavior of the plug-in is to use remote polling, does this mean we need to not use exclusion filters?
drdt 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.
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.
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.
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.