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

Wacky number for changes in build using Mercurial plugin

      It just shows random numbers for the changeset ids.

      This sounds like the same type of problem as JENKINS-7154, except I'm not using git. I'm using muti-scms with mercurial, so I'm not sure where the problem lies.

          [JENKINS-14365] Wacky number for changes in build using Mercurial plugin

          Jesse Glick added a comment -

          Odd. Probably a bug in multiple-scms. For example, http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/9339/changes shows changes 1-10 but the #9339 section of http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes shows 93, 94, 740, 741, 43638, 43639, 43640, 43641, 529, and 1!

          Jesse Glick added a comment - Odd. Probably a bug in multiple-scms. For example, http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/9339/changes shows changes 1-10 but the #9339 section of http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes shows 93, 94, 740, 741, 43638, 43639, 43640, 43641, 529, and 1!

          Jesse Glick added a comment -

          Visible at http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes for example: third item in build #9339 is displayed as "740. Performance: ..." because HTML has <li value="0740d2a6bcb311de7531ef4c9f4e3838274b990f">Performance: ..." which is wrong.

          Jesse Glick added a comment - Visible at http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes for example: third item in build #9339 is displayed as "740. Performance: ..." because HTML has <li value="0740d2a6bcb311de7531ef4c9f4e3838274b990f">Performance: ..." which is wrong.

          Jesse Glick added a comment -

          Trying to add cause in a comment, but failing so far...

          Jesse Glick added a comment - Trying to add cause in a comment, but failing so far...

          Jesse Glick added a comment -

          <li value="0740d2a6bcb311de7531ef4c9f4e3838274b990f"> for example at http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes shows as item #740.

          Jesse Glick added a comment - <li value="0740d2a6bcb311de7531ef4c9f4e3838274b990f"> for example at http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/changes shows as item #740.

          Jesse Glick added a comment - - edited

          In fact reproducible without multiple-scms plugin, just on a plain job using Mercurial. The problem is in jenkins/core/src/main/resources/hudson/scm/SCM/project-changes.jelly which uses <li value="${c.revision}"> even though no getRevision method is defined in the core ChangeLogSet.Entry (MercurialChangeSet happens to define it without overriding).

          Jesse Glick added a comment - - edited In fact reproducible without multiple-scms plugin, just on a plain job using Mercurial. The problem is in jenkins/core/src/main/resources/hudson/scm/SCM/project-changes.jelly which uses <li value="${c.revision}"> even though no getRevision method is defined in the core ChangeLogSet.Entry ( MercurialChangeSet happens to define it without overriding).

          Jesse Glick added a comment -

          JENKINS-7154 worked around this problem by adding a custom GitSCM/project-changes.jelly, but that just begs the question of why the default page has code which does nothing for an SCM which does not happen to provide a method named getRevision, and does something clearly wrong for an SCM which does.

          Jesse Glick added a comment - JENKINS-7154 worked around this problem by adding a custom GitSCM/project-changes.jelly , but that just begs the question of why the default page has code which does nothing for an SCM which does not happen to provide a method named getRevision , and does something clearly wrong for an SCM which does.

          Jesse Glick added a comment -

          To answer my own question: because SubversionChangeLogSet.LogEntry does define an public int getRevision() which is meaningful. Really it should have been the Subversion plugin which defined a custom project-changes.jelly with the special behavior of replacing list item numbers with Subversion revision numbers, a trick that of course is only meaningful for centralized SCMs which use integer revision numbers.

          The various fix options are:

          1. Remove value="${c.revision}" in core, override project-changes.jelly in the Subversion plugin, and eventually remove the project-changes.jelly override in the Git plugin (and anywhere else this might have been worked around) perhaps once the core fix makes it into an LTS release.

          2. Work around in the Mercurial plugin the same way as in the Git plugin, basically compounding the error.

          3. Change core to use getRevision only if it returns an Integer, rather than a String as the Git or Mercurial plugins would.

          Jesse Glick added a comment - To answer my own question: because SubversionChangeLogSet.LogEntry does define an public int getRevision() which is meaningful. Really it should have been the Subversion plugin which defined a custom project-changes.jelly with the special behavior of replacing list item numbers with Subversion revision numbers, a trick that of course is only meaningful for centralized SCMs which use integer revision numbers. The various fix options are: 1. Remove value="${c.revision}" in core, override project-changes.jelly in the Subversion plugin, and eventually remove the project-changes.jelly override in the Git plugin (and anywhere else this might have been worked around) perhaps once the core fix makes it into an LTS release. 2. Work around in the Mercurial plugin the same way as in the Git plugin, basically compounding the error. 3. Change core to use getRevision only if it returns an Integer , rather than a String as the Git or Mercurial plugins would.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/resources/hudson/scm/SCM/project-changes.jelly
          http://jenkins-ci.org/commit/jenkins/63b829a482431cdd4e4592ca78799412f4dead5a
          Log:
          [FIXED JENKINS-14365] Show a ChangeLogSet.Entry.revision as a <li> value only if it is in fact an Integer.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/resources/hudson/scm/SCM/project-changes.jelly http://jenkins-ci.org/commit/jenkins/63b829a482431cdd4e4592ca78799412f4dead5a Log: [FIXED JENKINS-14365] Show a ChangeLogSet.Entry.revision as a <li> value only if it is in fact an Integer.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html http://jenkins-ci.org/commit/jenkins/051b0016c4500b317c904b88eb6398b13538f218 Log: JENKINS-14365 Noted. Compare: https://github.com/jenkinsci/jenkins/compare/3f8ea1923b37...051b0016c450

          dogfood added a comment -

          Integrated in jenkins_main_trunk #1805

          Result = UNSTABLE

          dogfood added a comment - Integrated in jenkins_main_trunk #1805 Result = UNSTABLE

            jglick Jesse Glick
            dwatson David Watson
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: