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
          rpocase Robby Pocase added a comment -

          We use this pretty heavily as well, but not seeing this with p4-plugin 1.4.12. Not sure if its more directly related to your Jenkins upgrade (we're on 2.19.2).

          Show
          rpocase Robby Pocase added a comment - We use this pretty heavily as well, but not seeing this with p4-plugin 1.4.12. Not sure if its more directly related to your Jenkins upgrade (we're on 2.19.2).
          Hide
          rpocase Robby Pocase added a comment -

          I retested this with p4-plugin 1.4.13 and Jenkins 2.32.1 (in a docker container) in preparation for a Jenkins upgrade and wasn't able to reproduce this. Seems like there is something specific to your environment that's causing this.

          Show
          rpocase Robby Pocase added a comment - I retested this with p4-plugin 1.4.13 and Jenkins 2.32.1 (in a docker container) in preparation for a Jenkins upgrade and wasn't able to reproduce this. Seems like there is something specific to your environment that's causing this.
          Hide
          ram237 Pavel Pigalov added a comment - - edited

          Hi Robby, thanks for trying this.
          I've updated to 1.4.13 and still experience the same issue.

          Probably the thing is in the setup, I've got the following schema:

          • PARENT_JOB - MultiJob Project with parameters, including BUILD_NUMBER parameter which is "now" by default
            • CHILD_JOB1 - Freestyle Project that has "Pin build at Perforce Label" set to ${BUILD_NUMBER}
            • CHILD_JOB2 - Freestyle Project ...

          In my case PARENT_JOB receives the correct revision number, but all CHILD_JOBs receive it as plain "now" text which results in what is listed above in the issue description.

          Show
          ram237 Pavel Pigalov added a comment - - edited Hi Robby, thanks for trying this. I've updated to 1.4.13 and still experience the same issue. Probably the thing is in the setup, I've got the following schema: PARENT_JOB - MultiJob Project with parameters, including BUILD_NUMBER parameter which is "now" by default CHILD_JOB1 - Freestyle Project that has " Pin build at Perforce Label " set to ${BUILD_NUMBER} CHILD_JOB2 - Freestyle Project ... In my case PARENT_JOB receives the correct revision number, but all CHILD_JOBs receive it as plain "now" text which results in what is listed above in the issue description.
          Hide
          ram237 Pavel Pigalov added a comment - - edited

          Nope, when jobs have "Pin build at Perforce Label" set to ${BUILD_NUMBER} they always get "now" as plain text, no matter whether it is child or parent job.

          I'm really looking forward on solution for this issue, otherwise I will have to stay on p4-plugin v1.4.2 forever =)

          Show
          ram237 Pavel Pigalov added a comment - - edited Nope, when jobs have " Pin build at Perforce Label " set to ${BUILD_NUMBER} they always get "now" as plain text, no matter whether it is child or parent job. I'm really looking forward on solution for this issue, otherwise I will have to stay on p4-plugin v1.4.2 forever =)
          Hide
          ram237 Pavel Pigalov added a comment -

          With Jenkins 2.32.1 + p4-plugin 1.4.13 I've got the very same behavior

          Show
          ram237 Pavel Pigalov added a comment - With Jenkins 2.32.1 + p4-plugin 1.4.13 I've got the very same behavior
          Hide
          ram237 Pavel Pigalov added a comment -

          Ok, via dividing by 2 I have discovered that I do not experience the issue on p4-plugin 1.4.6, starting to have it from 1.4.7.
          This should help to track down the issue easier, since breaking changes were submitted into 1.4.7.

          ( jic, link to plugin versions: http://updates.jenkins-ci.org/download/plugins/p4/ )

          Show
          ram237 Pavel Pigalov added a comment - Ok, via dividing by 2 I have discovered that I do not experience the issue on p4-plugin 1.4.6, starting to have it from 1.4.7. This should help to track down the issue easier, since breaking changes were submitted into 1.4.7. ( jic, link to plugin versions: http://updates.jenkins-ci.org/download/plugins/p4/ )
          Hide
          ram237 Pavel Pigalov added a comment -
          Show
          ram237 Pavel Pigalov added a comment - I really suspect this change: https://swarm.workshop.perforce.com/changes/20620
          Hide
          p4paul Paul Allen added a comment -

          I'm a little bit puzzled by this. Perforce will never report a change as 'now' even if it is used in the revision specification. The p4-plugin does not set a change to 'now' (only tests for it's existence and uses it in the revision specifications).  

          So this only leaves user input; a user can set 'now' as a 'Pin build at Perforce Label' option, a LABEL parameter or part of a review. There is also the possibility that another plugin is setting now and passing it down to the p4-plugin.

          Pinning a build to 'now' should be avoided and not necessary as an unpinned change is calculated at the start of the Jenkins `Run` and used throughout the build.

          Show
          p4paul Paul Allen added a comment - I'm a little bit puzzled by this. Perforce will never report a change as 'now' even if it is used in the revision specification. The p4-plugin does not set a change to 'now' (only tests for it's existence and uses it in the revision specifications).   So this only leaves user input; a user can set 'now' as a 'Pin build at Perforce Label' option, a LABEL parameter or part of a review. There is also the possibility that another plugin is setting now and passing it down to the p4-plugin. Pinning a build to 'now' should be avoided and not necessary as an unpinned change is calculated at the start of the Jenkins `Run` and used throughout the build.
          Hide
          ram237 Pavel Pigalov added a comment -

          Hi Paul, thanks for your attention to this.

          Do you mean I need to leave ${BUILD_NUMBER} blank instead of putting "now" to sync to head prior to the build?

          Show
          ram237 Pavel Pigalov added a comment - Hi Paul, thanks for your attention to this. Do you mean I need to leave ${BUILD_NUMBER } blank instead of putting "now" to sync to head prior to the build?
          Hide
          p4paul Paul Allen added a comment - - edited

          Hi Pavel, I'm not sure where ${BUILD_NUMBER} is used in your environment? Please note I have never used the Multijob plugin. In general I would avoid using 'now' anywhere that might get inherited by the p4-plugin.

          Show
          p4paul Paul Allen added a comment - - edited Hi Pavel, I'm not sure where ${BUILD_NUMBER} is used in your environment? Please note I have never used the Multijob plugin. In general I would avoid using 'now' anywhere that might get inherited by the p4-plugin.
          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: