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

P4_CHANGELIST is no longer resolved into a number (shown as "now")

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Won't Fix
    • Component/s: p4-plugin
    • Labels:
      None
    • Environment:
      Jenkins v2.36 (also reproducible with v2.32.1, in fact Jenkins version is not important, I believe)
      p4-plugin v1.4.12 (issue started from v1.4.7)
      OS: Mac OSX El Capitan 10.11.1
    • Similar Issues:

      Description

      I've upgraded from Jenkins 1.653 to 2.36 and P4-Plugin from 1.4.2 to 1.4.12 today and immediately started facing this issue, which broken all my CI build infrstructure, since my bash scripts relay on number provided by P4_CHANGELIST variable.

      The issue is that it stores "now" instead of revision number if SCM is synced to head:

      As I understand this is only when "Pin build at Perforce Label" is set to "now", e.g. via a Parameter variable.

      From build console output:

      P4 Task: syncing files at client/label: now
      ...
      + echo P4_CHANGELIST
      now
      ...
      Set build name.
      New build name is 'now'

      Previously was:

      P4 Task: syncing files at change: 171134
      ...
      + echo P4_CHANGELIST
      171134
      ...
      Set build name.
      New build name is '171134'

      Is it some new design or a bug?
      If it is new design intent, then this makes P4 plugin almost unusable for me...

      I suppose this may have changed/been broken during changes made for env vars to work in Pipeline plugin...

      Not sure at which version it is started, going to downgrade and experiment (reverting back to 1.4.2 helped to return to previous behavior).

       

      p.s. refer to comments for more details found during a bit deeper investigation of this issue...

        Attachments

          Activity

          Hide
          ram237 Pavel Pigalov added a comment -

          Okay, got it. I will try to rework my job configurations and scripts to avoid "now" as the p4 label and see how it goes.

          As I mentioned above, "Pin build at Perforce Label" is set to ${BUILD_NUMBER} in all of my build stage jobs (this is the parameter available to be modified when user selects to build the job manually, currently the default value for it is set to "now" everywhere on my Jenkins and this worked perfectly until P4 Plugin  v1.4.6 inclusive).

          Multijob is not related in fact, as I also mentioned above in my comments when started investigating this deeper.

          Show
          ram237 Pavel Pigalov added a comment - Okay, got it. I will try to rework my job configurations and scripts to avoid "now" as the p4 label and see how it goes. As I mentioned above, " Pin build at Perforce Label " is set to ${BUILD_NUMBER } in all of my build stage jobs (this is the parameter available to be modified when user selects to build the job manually, currently the default value for it is set to "now" everywhere on my Jenkins and this worked perfectly until P4 Plugin  v1.4.6 inclusive). Multijob is not related in fact, as I also mentioned above in my comments when started investigating this deeper.
          Hide
          p4paul Paul Allen added a comment -

          Try setting the ${BUILD_NUMBER}  to an empty string when it is not being used.  The code ignores `null` or empty values in the "Pin build at Perforce Label" field.

          Show
          p4paul Paul Allen added a comment - Try setting the  ${BUILD_NUMBER }  to an empty string when it is not being used.  The code ignores `null` or empty values in the "Pin build at Perforce Label" field.
          Hide
          ram237 Pavel Pigalov added a comment -

          Hi Paul, I finally had the chance to try this and it worked pretty fine.

          So, I would accept such approach as a solution for the current case.

          Show
          ram237 Pavel Pigalov added a comment - Hi Paul, I finally had the chance to try this and it worked pretty fine. So, I would accept such approach as a solution for the current case.
          Hide
          ram237 Pavel Pigalov added a comment -

          Moving to Resolved without any fix from code side as per notes above.

          SOLUTION is not to use "now" as an indication of head revision, just leave the corresponding parameters values empty instead.

          Show
          ram237 Pavel Pigalov added a comment - Moving to Resolved without any fix from code side as per notes above. SOLUTION is not to use "now" as an indication of head revision, just leave the corresponding parameters values empty instead.
          Hide
          p4paul Paul Allen added a comment -

          Thank you for looking at and closing the issue.

          One final note; Using an empty string will build the latest change and record the change number in the build history, however using now records 'now' in the build history.

          Show
          p4paul Paul Allen added a comment - Thank you for looking at and closing the issue. One final note; Using an empty string will build the latest change and record the change number in the build history, however using now records 'now' in the build history.

            People

            • Assignee:
              Unassigned
              Reporter:
              ram237 Pavel Pigalov
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: