Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
-
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
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
Juan Ramos Fuentes
added a comment - markewaite Thank you for your response. I was facing the same issue as padamstx - in my case, I had an include region definition. Removing it fixed the issue. However, I would still like to have the include region definition. What is the best way to go about this, since it is not possible in a Freestyle project?
Juan Ramos Fuentes
added a comment - markewaite Thank you for your response. I was facing the same issue as padamstx - in my case, I had an include region definition. Removing it fixed the issue. However, I would still like to have the include region definition. What is the best way to go about this, since it is not possible in a Freestyle project? 
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.
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. 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!
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! 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?
jdramosf there isn't a way to use remote polling and honor include regions or honor exclude regions or honor exclude messages. Remote polling uses the git ls-remote command. The git ls-remote command is only able to return the remote branch name and the SHA-1 hash of that branch. Checking include regions and exclude regions and exclude messages requires a local copy of the repository so that the additional information needed is available.