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

P4 CHANGES_SINCE_LAST_BUILD stopped working in 1.13.0

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • p4-plugin
    • None

    Description

      We use the P4 plugin to provide an email changelog with the following format:

      ${CHANGES_SINCE_LAST_BUILD, showDependencies=true, format="\n[%r]\n\t%m\t\t%a - %d\n%p"}

      It has worked for years (a really long time), but ever since P4 1.13.0 was released the change section has been empty (specifically, "Changes: No changes").

      Rolling back to 1.12.4 immediately restores the "changes since last build" functionality. All other p4 functions work fine, it is only the changes that do not populate.

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          sbush1310 Steven added a comment -

          This also affects the Jenkins Job result summaries. For the jenkins job, viewing "Changes" results in:

          <icon> No changes from last build.
<icon> Started by an SCM change

          As with bodenste, rolling back to 1.12.4 fixes the issue. This is a high priority issue for us and we will not be able to upgrade further until this is sorted out.

          sbush1310 Steven added a comment - This also affects the Jenkins Job result summaries. For the jenkins job, viewing "Changes" results in: <icon> No changes from last build. <icon> Started by an SCM change As with bodenste , rolling back to 1.12.4 fixes the issue. This is a high priority issue for us and we will not be able to upgrade further until this is sorted out.
          joel_brown Joel Brown added a comment -

          This could be because the Perforce global option (System Configuration/Configure System), option "Maximum number of changes shown in a build", has altered its behaviour.

          A value of "0" used to mean the default - 20.

          Now, "0" means 0.

          joel_brown Joel Brown added a comment - This could be because the Perforce global option (System Configuration/Configure System), option "Maximum number of changes shown in a build", has altered its behaviour. A value of "0" used to mean the default - 20. Now, "0" means 0.
          sbush1310 Steven added a comment -

          Thanks for that, I went back and re-read the release notes from 1.13.0 and found this:

          Merge pull request #145 from joel-f-brown/master. Allow option to not detect changelists for build, JENKINS-68516

          Perhaps a more detailed comment on the submission might have helped

          The "0" seems to have been the default value when the tool is first installed. I just migrated our Jenkins server from 2.89.2 to the latest LTS, and so I migrated from the original plugin to the new one during the upgrade, and so this was a brand new plugin installation. The default value seems to be 0.

          It's possible that a prior maintainer at my site had previously installed and removed the new plug-in, so it's possible that the default is not 0 as I stated, but if the default is currently "0", I would recommend changing the default setting for new installations to be 20. If people want to turn it off, that's fine, but I don't believe disabled changes detection should be the default.

          sbush1310 Steven added a comment - Thanks for that, I went back and re-read the release notes from 1.13.0 and found this: Merge pull request #145 from joel-f-brown/master. Allow option to not detect changelists for build, JENKINS-68516 Perhaps a more detailed comment on the submission might have helped The "0" seems to have been the default value when the tool is first installed. I just migrated our Jenkins server from 2.89.2 to the latest LTS, and so I migrated from the original plugin to the new one during the upgrade, and so this was a brand new plugin installation. The default value seems to be 0. It's possible that a prior maintainer at my site had previously installed and removed the new plug-in, so it's possible that the default is not 0 as I stated, but if the default is currently "0", I would recommend changing the default setting for new installations to be 20. If people want to turn it off, that's fine, but I don't believe disabled changes detection should be the default.
          joel_brown Joel Brown added a comment -

          I agree.

          Release notes should have had more detail. 

          The default should now be 20 for new installs, just as it was before (because 0 previously meant 20).  I'll look into that.

           

          joel_brown Joel Brown added a comment - I agree. Release notes should have had more detail.  The default should now be 20 for new installs, just as it was before (because 0 previously meant 20).  I'll look into that.  
          joel_brown Joel Brown added a comment -

          Hi bodenste Does/did changing the "Maximum number of changes shown in a build" help?   

          I'm trying to determine if your issue is that or something different.

          joel_brown Joel Brown added a comment - Hi bodenste Does/did changing the "Maximum number of changes shown in a build" help?    I'm trying to determine if your issue is that or something different.
          bodenste Brian added a comment -

          Hi Joel,

           

          Yes! We just tested it and this was exactly the issue. The release notes did not make this obvious, and it was set to the default (0). I changed it to 20 and it's working great.

           

          Thanks so much!!

          bodenste Brian added a comment - Hi Joel,   Yes! We just tested it and this was exactly the issue. The release notes did not make this obvious, and it was set to the default (0). I changed it to 20 and it's working great.   Thanks so much!!

          People

            Unassigned Unassigned
            bodenste Brian
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated: