[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Phil Adams commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new Jacob, thanks for the info... it turns out that I did in fact have the "author in change log" option selected, and that was why workspace polling was being used. By disabling that option, the plugin started doing remote polling. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50683) Git plugin polling requires workspace even when "Force polling using workspace" is NOT defined
Title: Message Title Phil Adams commented on JENKINS-50683 Re: Git plugin polling requires workspace even when "Force polling using workspace" is NOT defined 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. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50683) Git plugin polling requires workspace even when "Force polling using workspace" is NOT defined
Title: Message Title Phil Adams commented on JENKINS-50683 Re: Git plugin polling requires workspace even when "Force polling using workspace" is NOT defined 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! Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50683) Git plugin polling requires workspace even when "Force polling using workspace" is NOT defined
Title: Message Title Phil Adams created an issue Jenkins / JENKINS-50683 Git plugin polling requires workspace even when "Force polling using workspace" is NOT defined Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2018-04-09 17:17 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 Priority: Minor Reporter: Phil Adams 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
[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Phil Adams commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new Thanks Jacob, do you know how I could tell the git plugin to use the remote polling method instead of requiring a workspace? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Phil Adams edited a comment on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I just thought to check the "Polling log" section of my build results and for the offending job (which builds my 0.0.1 branch), I see this:--Started on Apr 6, 2018 5:02:00 PM Workspace is offline. Scheduling a new build to get a workspace. (nonexisting_workspace) Done. Took 0 ms Changes found--So... it looks like the job is triggered each time because the jenkins server can't find an existing workspace where a previous build has been performed. Am I understanding that correctly?Is there no way to detect changes on a branch without having an existing workspace with the branch checked out? In my case, our jenkins server assigns build jobs to agents running in a docker swarm, where the agent is effectively wiped clean after ever every build, hence a subsequent build will be done on a completely clean randomly-assigned agent. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Phil Adams commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I just thought to check the "Polling log" section of my build results and for the offending job (which builds my 0.0.1 branch), I see this: -- Started on Apr 6, 2018 5:02:00 PM Workspace is offline. Scheduling a new build to get a workspace. (nonexisting_workspace) Done. Took 0 ms Changes found -- So... it looks like the job is triggered each time because the jenkins server can't find an existing workspace where a previous build has been performed. Am I understanding that correctly? Is there no way to detect changes on a branch without having an existing workspace with the branch checked out? In my case, our jenkins server assigns build jobs to agents running in a docker swarm, where the agent is effectively wiped clean after ever build, hence a subsequent build will be done on a completely clean randomly-assigned agent. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Phil Adams edited a comment on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I'm having the same issue. My github enterprise repo has two branches - "master" and "0.0.1" - and I have two jenkins jobs defined (one for each branch... i.e. the branch specifier in each job definition is set to "*/"). In my github repository, I've configured the webhook url (https:///git/notifyCommit?url="" When I hit the webhook URL (testing from github), jenkins receives the POST and pokes the correct jobs, but it incorrectly things there are changes on each of the branches, so it triggers a build for each one.While trying to get the git push triggering to work with the GitHub plugin, I see the same exact behavior. A push to one branch triggers both builds to start, even though the push was to only one of the branches. So it seems like the basic issue here is when the git plugin looks to see if there are changes on a branch, it always thinks there are changes even when no commits have been pushed since the last build.Edit: In case it matters, I'm using Jenkins v2.89.2 with the Git Plugin v3.8.0 Edit: Just wanted clarify a couple things... I think my scenario is simpler than the one described by the issue originator. I temporarily changed one of my jobs (for the 0.0.1 branch) to use polling (every 2 minutes for testing purposes) rather than the webhook. Without any changes being pushed to my 0.0.1 branch, the first time the polling ran it thought there were changes present so it triggered a build. And subsequent to that, each time the polling is initiated (every 2 minutes), it thinks there is a change and triggers a build. Is there anything I can do via configuration to fix this? Also, if there is some additional server logging that I can enable to try to determine why this is broken, I'm happy to do that as well.Thanks! Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Phil Adams edited a comment on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I'm having the same issue. My github enterprise repo has two branches - "master" and "0.0.1" - and I have two jenkins jobs defined (one for each branch... i.e. the branch specifier in each job definition is set to "*/"). In my github repository, I've configured the webhook url (https:///git/notifyCommit?url="" When I hit the webhook URL (testing from github), jenkins receives the POST and pokes the correct jobs, but it incorrectly things there are changes on each of the branches, so it triggers a build for each one.While trying to get the git push triggering to work with the GitHub plugin, I see the same exact behavior. A push to one branch triggers both builds to start, even though the push was to only one of the branches. So it seems like the basic issue here is when the git plugin looks to see if there are changes on a branch, it always thinks there are changes even when no commits have been pushed since the last build. Edit: In case it matters, I'm using Jenkins v2.89.2 with the Git Plugin v3.8.0 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50556) git polling succeeds even when origin/master has nothing new
Title: Message Title Phil Adams commented on JENKINS-50556 Re: git polling succeeds even when origin/master has nothing new I'm having the same issue. My github enterprise repo has two branches - "master" and "0.0.1" - and I have two jenkins jobs defined (one for each branch... i.e. the branch specifier in each job definition is set to "*/"). In my github repository, I've configured the webhook url (https:///git/notifyCommit?url="" When I hit the webhook URL (testing from github), jenkins receives the POST and pokes the correct jobs, but it incorrectly things there are changes on each of the branches, so it triggers a build for each one. While trying to get the git push triggering to work with the GitHub plugin, I see the same exact behavior. A push to one branch triggers both builds to start, even though the push was to only one of the branches. So it seems like the basic issue here is when the git plugin looks to see if there are changes on a branch, it always thinks there are changes even when no commits have been pushed since the last build. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
