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

Build with Poll SCM trigger proceeds even though no SCM change

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Minor Minor
    • subversion-plugin
    • None
    • linux

      I have a Jenkins jobs setup to poll SCM nightly and run a build if there are changes. The problem is if there are no changes, Jenkins executes the job anyway.

      Here is console output of a simple job that polls SCM and then executes a single build step (shell command of "echo blah").

      attached is a screenshot of the console output (also available here: http://i.imgur.com/5jQTIAe.png)

      You can see, even though there were no SCM changes, the build continues. The behavior I am looking for is if there is no change, the build steps are not executed. Also strange is the first thing in the output is "Started by an SCM change", followed by an indication that there was in fact no change.

          [JENKINS-21288] Build with Poll SCM trigger proceeds even though no SCM change

          Mark Waite added a comment -

          Can you provide a repeatable set of steps which show the problem?

          JENKINS-20286 reports a problem with detailed steps for the JGit implementation in the Git plugin. The same steps using the Git command line implementation in the Git plugin do not show the problem. Since the problem only affects one of the two implementations in the Git plugin, I'm reasonably confident that issue is in the Git plugin rather than in Jenkins core or the git-scm plugin.

          Mark Waite added a comment - Can you provide a repeatable set of steps which show the problem? JENKINS-20286 reports a problem with detailed steps for the JGit implementation in the Git plugin. The same steps using the Git command line implementation in the Git plugin do not show the problem. Since the problem only affects one of the two implementations in the Git plugin, I'm reasonably confident that issue is in the Git plugin rather than in Jenkins core or the git-scm plugin.

          Grigoriy Milman added a comment - - edited

          Our case is described in JENKINS-21260.

          We moved from PTC integrity plugin from 1.18 to 1.19. At the same time we updated Jenkins from 1.535 to 1.545.
          We have seen some issues there and roll back both plugin and Jenkins. After that a new version of Jenkins and plugin appeared. We have updated Jenkins to 1.546 and PTC plugin to 1.20 and after that we have instant triggering during each poll.

          Grigoriy Milman added a comment - - edited Our case is described in JENKINS-21260 . We moved from PTC integrity plugin from 1.18 to 1.19. At the same time we updated Jenkins from 1.535 to 1.545. We have seen some issues there and roll back both plugin and Jenkins. After that a new version of Jenkins and plugin appeared. We have updated Jenkins to 1.546 and PTC plugin to 1.20 and after that we have instant triggering during each poll.

          Charles Jones added a comment -

          @Mark Waite

          Repeatable steps (at least for me) are:

          1. Create a simple job with a single build step. In my case the build step is "execute shell", with a single command "echo blah"
          2. Set "Source Code Management" in the job config to "Subversion", specify my repo URL, leave other SCM options at default settings.
          3. Utilize "Restrict where this project can be run" and specify the label of the slave node that has access to the SVN repo.
          4. Set a Build Trigger for "Poll SCM". I am using a schedule of "50 15 * * 1-5" which should kick the job off at 3:50pm on weekdays.

          I am not sure if the issue is caused by a slave polling the SCM. Unfortunately the Master node/server has no access to the SCM for me to do any testing to rule out a slave polling issue.

          Here is the full sanitized text of a "success" (indicates there is no change, yet it executes the build step anyway):

          Started by an SCM change
          [EnvInject] - Loading node environment variables.
          Building remotely on Slave-Dev in workspace /xxx/jenkins/SLAVE/workspace/SVN_Polling_Test
          Updating https://xxx.com/svn/repos/xxx/yyy at revision '2014-01-13T15:52:25.657 +0000'
          At revision 10400
          no change for https://xxx.com/svn/repos/xxx/yyy since the previous build
          [SVN_Polling_Test] $ /bin/sh -xe /xxx/jenkins/TMP/hudson7599194012466459999.sh
          + echo blah
          blah
          Finished: SUCCESS

          And here is the full sanitized text of a "failure" (seemingly random failures to poll the SCM) that seems to happen often for the same job:

          Started by an SCM change
          [EnvInject] - Loading node environment variables.
          Building remotely on Slave-Dev in workspace /xxx/jenkins/SLAVE/workspace/SVN_Polling_Test
          Updating https://xxx.com/svn/repos/xxx/yyy at revision '2014-01-17T15:51:55.337 +0000'
          At revision 10405
          hudson.util.IOException2: revision check failed on https://xxx.com/svn/repos/xxx/yyy
          at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:178)
          at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:113)
          at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:654)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:815)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1415)
          at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
          at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
          at hudson.model.Run.execute(Run.java:1678)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:231)
          Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /svn/repos/xxx/yyy failed
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
          at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118)
          at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148)
          at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45)
          at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160)
          at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
          at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967)
          at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872)
          at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:166)
          ... 11 more
          Caused by: svn: E175002: OPTIONS /svn/repos/xxx/yyy failed
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
          ... 30 more
          Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/svn/repos/xxx/yyy'
          svn: E175002: timed out waiting for server
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382)
          ... 29 more
          Caused by: svn: E175002: OPTIONS request failed on '/svn/repos/xxx/yyy'
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775)
          ... 30 more
          Caused by: svn: E175002: timed out waiting for server
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514)
          ... 30 more
          Caused by: java.net.SocketTimeoutException: connect timed out
          at java.net.PlainSocketImpl.socketConnect(Native Method)
          at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
          at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
          at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
          at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
          at java.net.Socket.connect(Socket.java:579)
          at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618)
          at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.connect(SVNSocketFactory.java:146)
          at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createSSLSocket(SVNSocketFactory.java:106)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:280)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:451)
          ... 30 more
          Finished: FAILURE

          Charles Jones added a comment - @Mark Waite Repeatable steps (at least for me) are: Create a simple job with a single build step. In my case the build step is "execute shell", with a single command "echo blah" Set "Source Code Management" in the job config to "Subversion", specify my repo URL, leave other SCM options at default settings. Utilize "Restrict where this project can be run" and specify the label of the slave node that has access to the SVN repo. Set a Build Trigger for "Poll SCM". I am using a schedule of "50 15 * * 1-5" which should kick the job off at 3:50pm on weekdays. I am not sure if the issue is caused by a slave polling the SCM. Unfortunately the Master node/server has no access to the SCM for me to do any testing to rule out a slave polling issue. Here is the full sanitized text of a "success" (indicates there is no change, yet it executes the build step anyway): Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on Slave-Dev in workspace /xxx/jenkins/SLAVE/workspace/SVN_Polling_Test Updating https://xxx.com/svn/repos/xxx/yyy at revision '2014-01-13T15:52:25.657 +0000' At revision 10400 no change for https://xxx.com/svn/repos/xxx/yyy since the previous build [SVN_Polling_Test] $ /bin/sh -xe /xxx/jenkins/TMP/hudson7599194012466459999.sh + echo blah blah Finished: SUCCESS And here is the full sanitized text of a "failure" (seemingly random failures to poll the SCM) that seems to happen often for the same job: Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on Slave-Dev in workspace /xxx/jenkins/SLAVE/workspace/SVN_Polling_Test Updating https://xxx.com/svn/repos/xxx/yyy at revision '2014-01-17T15:51:55.337 +0000' At revision 10405 hudson.util.IOException2: revision check failed on https://xxx.com/svn/repos/xxx/yyy at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:178) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:113) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:654) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:815) at hudson.model.AbstractProject.checkout(AbstractProject.java:1415) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /svn/repos/xxx/yyy failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:118) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:148) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:45) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:166) ... 11 more Caused by: svn: E175002: OPTIONS /svn/repos/xxx/yyy failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 30 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/svn/repos/xxx/yyy' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 29 more Caused by: svn: E175002: OPTIONS request failed on '/svn/repos/xxx/yyy' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 30 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:514) ... 30 more Caused by: java.net.SocketTimeoutException: connect timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.connect(SVNSocketFactory.java:146) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createSSLSocket(SVNSocketFactory.java:106) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:280) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:451) ... 30 more Finished: FAILURE

          Charles Jones added a comment -

          Issue still present in version 1.549. Is this going to get assigned to someone?

          Charles Jones added a comment - Issue still present in version 1.549. Is this going to get assigned to someone?

          Mark Waite added a comment -

          The problem description and the stack trace all seem to indicate a problem with the specific Subversion SCM plugin.

          In this case, it appears the Subversion plugin is sometimes throwing an exception. I think the core is behaving correctly that if polling throws an exception, it assumes there is a change, rather than assuming no change on an exception.

          I think that if a plugin independent component calls a plugin specific component to check for changes, and that plugin specific component throws an exception, I'd rather have the plugin independent portion assume there was a change, rather than have it assume that an exception meant no change.

          I think this specific bug report is about Subversion and needs to be assigned to the Subversion plugin, rather than being assigned to scm-api, since I think the scm-api is behaving correctly in this case.

          Mark Waite added a comment - The problem description and the stack trace all seem to indicate a problem with the specific Subversion SCM plugin. In this case, it appears the Subversion plugin is sometimes throwing an exception. I think the core is behaving correctly that if polling throws an exception, it assumes there is a change, rather than assuming no change on an exception. I think that if a plugin independent component calls a plugin specific component to check for changes, and that plugin specific component throws an exception, I'd rather have the plugin independent portion assume there was a change, rather than have it assume that an exception meant no change. I think this specific bug report is about Subversion and needs to be assigned to the Subversion plugin, rather than being assigned to scm-api, since I think the scm-api is behaving correctly in this case.

          We have seen this issue with PTC SCM plugin. We are not using Subversion. See my comments the very top here

          Grigoriy Milman added a comment - We have seen this issue with PTC SCM plugin. We are not using Subversion. See my comments the very top here

          Mark Waite added a comment -

          I recommend a separate bug report for those SCM systems which show the problem. As far as I can tell from comments by Cletus D'Souza, the PTC Integrity SCM plugin is still maintained by him and its bugs are still tracked in the Jenkins Jira instance.

          You said in your first posting that "it seems more general". I disagree. I don't think it is more general. I think the cases which cause the problem are specific to each plugin. That was certainly the case for the example which was reported against the Git plugin. Changes in core Jenkins or in the scm-api plugin would not have fixed the issue in the git plugin. I suspect it is the same for your PTC Integrity case.

          Mark Waite added a comment - I recommend a separate bug report for those SCM systems which show the problem. As far as I can tell from comments by Cletus D'Souza, the PTC Integrity SCM plugin is still maintained by him and its bugs are still tracked in the Jenkins Jira instance. You said in your first posting that "it seems more general". I disagree. I don't think it is more general. I think the cases which cause the problem are specific to each plugin. That was certainly the case for the example which was reported against the Git plugin. Changes in core Jenkins or in the scm-api plugin would not have fixed the issue in the git plugin. I suspect it is the same for your PTC Integrity case.

          Charles Jones added a comment -

          I've added subversion to the ticket components. Is there anything else I can do to get it properly looked at?

          Charles Jones added a comment - I've added subversion to the ticket components. Is there anything else I can do to get it properly looked at?

          Mark Waite added a comment -

          Since Jenkins is an open source project, investigation happens when one of the volunteers on the project finds it interesting enough to investigate. Alternately, investigation can happen when someone purchases commercial support from one of the commercial support vendors (like CloudBees). Investigation can also happen when someone decides to learn enough of the code to perform that investigation themselves.

          If you can provide more details about the conditions which cause it to fail, sometimes that can encourage more interest from the developers on the project.

          If you can show that the problem is more widespread than just your installation, sometimes that can encourage more interest from the developers on the project.

          Mark Waite added a comment - Since Jenkins is an open source project, investigation happens when one of the volunteers on the project finds it interesting enough to investigate. Alternately, investigation can happen when someone purchases commercial support from one of the commercial support vendors (like CloudBees). Investigation can also happen when someone decides to learn enough of the code to perform that investigation themselves. If you can provide more details about the conditions which cause it to fail, sometimes that can encourage more interest from the developers on the project. If you can show that the problem is more widespread than just your installation, sometimes that can encourage more interest from the developers on the project.

          cjones Did you try with the latest release of Subversion Plugin? Which Jenkins version are you using?

          Manuel Recena Soto added a comment - cjones Did you try with the latest release of Subversion Plugin? Which Jenkins version are you using?

            recena Manuel Recena Soto
            cjones Charles Jones
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: