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

no change infos are displayed although poll says there are changes

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • subversion-plugin
    • None
    • Jenkins 1.638
      Subversion Plugin 2.5.4

      When updating subversion plugin to 2.5.4 we have the following inconsistent buildinformation:
      for changes it says "No changes" while it says "Started by an SCM change". When looking at the poll information we see that there have been changes in subversion.
      When we downgrade the subversion plugin to version 2.4.5 we don't see this (change information is displayed on build page)

          [JENKINS-31796] no change infos are displayed although poll says there are changes

          trejkaz added a comment -

          We see this too, on Jenkins 2.46 + Subversion Plugin 2.7.1.

          Dump of what I see on Jenkins pages:

          On the build info page for Job #4056:

          Build #4056 (28-Feb-2017 15:06:00)
          Revision: 62718
          Changes:
            * ACME-12290: Summary of commit (detail)
            * ACME-12412 Summary of commit (detail)
          Started by an SCM change
          

          Polling log for Job #4056:

          Started on 28/02/2017 3:01:01 PM
          Received SCM poll call on master for trunk-compile on 28/02/2017 3:01:01 PM
          https://svn/acme/trunk/product is at revision 62,717
            (changed from 62,716)
          Done. Took 0.1 sec
          Changes found
          

          On the build info page for Job #4057:

          Build #4057 (28-Feb-2017 15:07:35)
          Revision: 62718
          No changes
          Started by an SCM change
          

          Polling log for Job #4057:

          Started on 28/02/2017 3:06:01 PM
          Received SCM poll call on master for trunk-compile on 28/02/2017 3:06:01 PM
          https://svn/acme/trunk/product is at revision 62,718
            (changed from 62,717)
          Done. Took 86 ms
          Changes found
          

          trejkaz added a comment - We see this too, on Jenkins 2.46 + Subversion Plugin 2.7.1. Dump of what I see on Jenkins pages: On the build info page for Job #4056: Build #4056 (28-Feb-2017 15:06:00) Revision: 62718 Changes: * ACME-12290: Summary of commit (detail) * ACME-12412 Summary of commit (detail) Started by an SCM change Polling log for Job #4056: Started on 28/02/2017 3:01:01 PM Received SCM poll call on master for trunk-compile on 28/02/2017 3:01:01 PM https://svn/acme/trunk/product is at revision 62,717 (changed from 62,716) Done. Took 0.1 sec Changes found On the build info page for Job #4057: Build #4057 (28-Feb-2017 15:07:35) Revision: 62718 No changes Started by an SCM change Polling log for Job #4057: Started on 28/02/2017 3:06:01 PM Received SCM poll call on master for trunk-compile on 28/02/2017 3:06:01 PM https://svn/acme/trunk/product is at revision 62,718 (changed from 62,717) Done. Took 86 ms Changes found

          trejkaz added a comment -

          So adding in the known time of the commit, this is the series of events, and shows the bug pretty clearly:

          1. 15:01:01 - Polling starts:
            • Current code is revision 62,717
            • Previous revision was 62,716
            • Triggers a new job
          2. 15:05:19 - Revision 62718 is committed to svn
          3. 15:06:00 - Build #4056 starts:
            • Sees the latest revision as 62,718
            • Records changes from 62,716 ~ 62,718 into the job
            • Builds revision 62,718
          4. 15:06:01 - Polling starts:
            • Current code is revision 62,718
            • Previous revision was still 62,717, according to the poller, because it doesn't know which revision actually got built
            • Triggers a new job
          5. 15:07:35 - Build #4057 starts:
            • Sees the latest revision as 62,718
            • Last revision it built was 62,718, so it can't see any changes
            • Builds revision 62,718 anyway

          So essentially the poller and the job tracking don't know about each other's state, resulting in these perhaps-unnecessary builds.

          So basically, it seems that this could be resolved if any of the following were done:

          • The polling could have triggered the job for a specific revision.
          • The polling could be made aware of the latest revision actually built.
          • The polling could abort the build if no changes have occurred since the last build.

          trejkaz added a comment - So adding in the known time of the commit, this is the series of events, and shows the bug pretty clearly: 15:01:01 - Polling starts: Current code is revision 62,717 Previous revision was 62,716 Triggers a new job 15:05:19 - Revision 62718 is committed to svn 15:06:00 - Build #4056 starts: Sees the latest revision as 62,718 Records changes from 62,716 ~ 62,718 into the job Builds revision 62,718 15:06:01 - Polling starts: Current code is revision 62,718 Previous revision was still 62,717, according to the poller , because it doesn't know which revision actually got built Triggers a new job 15:07:35 - Build #4057 starts: Sees the latest revision as 62,718 Last revision it built was 62,718, so it can't see any changes Builds revision 62,718 anyway So essentially the poller and the job tracking don't know about each other's state, resulting in these perhaps-unnecessary builds. So basically, it seems that this could be resolved if any of the following were done: The polling could have triggered the job for a specific revision. The polling could be made aware of the latest revision actually built. The polling could abort the build if no changes have occurred since the last build.

          trejkaz added a comment -

          JENKINS-21288 also seems to be the same issue, but it was resolved saying that they couldn't reproduce it. I'm guessing that whoever tried probably had a project which built so quickly that the problem didn't occur, whereas those of us with real, large projects, will have it happen relatively often. :/

          trejkaz added a comment - JENKINS-21288 also seems to be the same issue, but it was resolved saying that they couldn't reproduce it. I'm guessing that whoever tried probably had a project which built so quickly that the problem didn't occur, whereas those of us with real, large projects, will have it happen relatively often. :/

            Unassigned Unassigned
            patrikf Patrik Fuerer
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: