• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None

      After upgrading to Hudson 1.379 (from 1.377), we are now seeing multiple "Polling Log" entries (see screenshot). All the links point to the same URL and all polling logs seem to be empty.

          [JENKINS-7649] Multiple Polling Log links

          Dirk Haun added a comment -

          Looks like it has to do with the "Started by an SCM change" message:

          When it says "Started by an SCM change (5 times)", we get 5 such links. When it says "Started by an SCM change (2 times)", we get 2 links, and so on.

          Also, the polling logs are not always empty. But they are always identical.

          Dirk Haun added a comment - Looks like it has to do with the "Started by an SCM change" message: When it says "Started by an SCM change (5 times)", we get 5 such links. When it says "Started by an SCM change (2 times)", we get 2 links, and so on. Also, the polling logs are not always empty. But they are always identical.

          MarkEWaite added a comment -

          I've also seen the same issue, multiple "Started by an SCM change" on our Hudson server since upgrading to 1.378. It is still visible in 1.379 as well.

          We're using the Git SCM plugin in case that is relevant.

          MarkEWaite added a comment - I've also seen the same issue, multiple "Started by an SCM change" on our Hudson server since upgrading to 1.378. It is still visible in 1.379 as well. We're using the Git SCM plugin in case that is relevant.

          jed624 added a comment -

          Also in 1.380. We're using the Perforce plugin.

          jed624 added a comment - Also in 1.380. We're using the Perforce plugin.

          Andrew Bayer added a comment -

          I would assume this is due to http://github.com/hudson/hudson-main/commit/14903e695a522ca833107f839eb2cf6926e30f63 - when a build is kicked off by SCM polling, the log is now captured. If a build is triggered by multiple SCM polling checks (say, four polling checks ran while the build itself was running, and all four saw (the same) new change), that'll result in what you're seeing. The problem, as I see it, is that all the polling checks are pointing to the same, most recent logfile, so we end up with a bunch of links all pointing to the same output. I'll take a look and see if this can be rationalized.

          Andrew Bayer added a comment - I would assume this is due to http://github.com/hudson/hudson-main/commit/14903e695a522ca833107f839eb2cf6926e30f63 - when a build is kicked off by SCM polling, the log is now captured. If a build is triggered by multiple SCM polling checks (say, four polling checks ran while the build itself was running, and all four saw (the same) new change), that'll result in what you're seeing. The problem, as I see it, is that all the polling checks are pointing to the same, most recent logfile, so we end up with a bunch of links all pointing to the same output. I'll take a look and see if this can be rationalized.

          Laird Nelson added a comment -

          Still present in 1.383.

          Laird Nelson added a comment - Still present in 1.383.

          rakslice added a comment -

          I'm seeing this on a job that has exclude paths defined for its SCM checkout using the SVN plugin. As above, the build page shows e.g. "Started by an SCM change (3 times)", there are the same number of links, and the polling logs are identical. The polling log(s) say "Ignored revision xxx: Found only excluded paths: ..."

          Just to clarify, what is the expected behaviour here? Should all of those polling logs be captured or just the last one, which should have actually triggered the build?

          rakslice added a comment - I'm seeing this on a job that has exclude paths defined for its SCM checkout using the SVN plugin. As above, the build page shows e.g. "Started by an SCM change (3 times)", there are the same number of links, and the polling logs are identical. The polling log(s) say "Ignored revision xxx: Found only excluded paths: ..." Just to clarify, what is the expected behaviour here? Should all of those polling logs be captured or just the last one, which should have actually triggered the build?

          Alan Harder added a comment -

          Hi abayer- planning to fix this soon? Otherwise please unassign, thx!

          Alan Harder added a comment - Hi abayer- planning to fix this soon? Otherwise please unassign, thx!

          Andrew Bayer added a comment -

          Working on this as we speak, actually.

          Andrew Bayer added a comment - Working on this as we speak, actually.

          Code changed in jenkins
          User: Andrew Bayer
          Path:
          changelog.html
          core/src/main/java/hudson/triggers/SCMTrigger.java
          test/src/test/java/hudson/triggers/SCMTriggerTest.java
          http://jenkins-ci.org/commit/core/0e541e66b69cef0e0c147cc9635e2ec800adaa5a
          Log:
          [FIXED JENKINS-7649] Only including one SCMTrigger.BuildAction per build, since there's only one possible polling log to link to.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: changelog.html core/src/main/java/hudson/triggers/SCMTrigger.java test/src/test/java/hudson/triggers/SCMTriggerTest.java http://jenkins-ci.org/commit/core/0e541e66b69cef0e0c147cc9635e2ec800adaa5a Log: [FIXED JENKINS-7649] Only including one SCMTrigger.BuildAction per build, since there's only one possible polling log to link to.

          dogfood added a comment -

          dogfood added a comment - Integrated in jenkins_main_trunk #514

            abayer Andrew Bayer
            dhaun Dirk Haun
            Votes:
            4 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: