• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • Jenkins Docker image 2.263.3, P4-plugin 2.11.1

      When upgrading from 1.9.5 to 2.11.1, it seems that matrix builds are broken as far as the Perforce sync is concerned.

      Effect of the upgrade: The plugin seems to cache and reuse the last workspace used for a given Perforce changelist. Although two different Perforce clients are defined for the matrix, a wrong client is therefore picked-up leading to the fatal "file not under client's root" message...

      Workaround: downgrade to 1.9.5 to get back functional matrix builds

          [JENKINS-64879] P4 plugin 2.11.1 broken for matrix builds ?

          Karl Wirth added a comment -

          Hi pnobili,

           

          Please get me some screenshots of how the matrix build is defined highlighting the different workspaces so I can try and reproduce this on my test systems.

           

          Regards,

           

          Karl

          Karl Wirth added a comment - Hi pnobili ,   Please get me some screenshots of how the matrix build is defined highlighting the different workspaces so I can try and reproduce this on my test systems.   Regards,   Karl

          Hi Karl,

          Thanks for the swift reply. Just a bit of context on what we do (the screenshot is below):

          We have many branches, but only one to sync. So, depending on what the user selects before building, instead of letting the plugin sync from the depot, we use the CheckOnlyImpl class, and perform the sync ourselves in the build-axis, using the environment variables set-up by the plugin (P4_PORT, P4_CLIENT, etc). 

          JENKINS_INSTANCE_NAME is defined at Jenkins startup (we build Jenkins as Docker containers on the fly). From what it seems, P4_CLIENT has not the expected value with this version of the plugin, but I might be mistaken... Thanks again.

          p4view is correctly defined, using the same environment variables as below and our Perforce depot specifics.

           

          Philippe Nobili added a comment - Hi Karl, Thanks for the swift reply. Just a bit of context on what we do (the screenshot is below): We have many branches, but only one to sync. So, depending on what the user selects before building, instead of letting the plugin sync from the depot, we use the CheckOnlyImpl class, and perform the sync ourselves in the build-axis, using the environment variables set-up by the plugin (P4_PORT, P4_CLIENT , etc).  JENKINS_INSTANCE_NAME is defined at Jenkins startup (we build Jenkins as Docker containers on the fly). From what it seems, P4_CLIENT has not the expected value with this version of the plugin, but I might be mistaken... Thanks again. p4view is correctly defined, using the same environment variables as below and our Perforce depot specifics.  

          Karl Wirth added a comment -

          Hi pnobili - Thanks. I not familiar with they

          I'd like some more detailed information, however it may contain sensitive data so you can either post it here or send an email to support@perforce.com and mention me in the title. Please get me:

          (1) Full console log for a job run that failed on 2.11.1.

          (2) Full console log for a job that worked just after the downgrade on 1.9.5.

          (3) The build.xml for the job.

          Thanks in advance,

          Karl

           

          Karl Wirth added a comment - Hi pnobili - Thanks. I not familiar with they I'd like some more detailed information, however it may contain sensitive data so you can either post it here or send an email to support@perforce.com and mention me in the title. Please get me: (1) Full console log for a job run that failed on 2.11.1. (2) Full console log for a job that worked just after the downgrade on 1.9.5. (3) The build.xml for the job. Thanks in advance, Karl  

          Hi Karl,

          Thanks for coming back to me on this.

          We created a tiny Jenkins project that demonstrates what is the problem is (attached here).

           

           To make it short: P4_CLIENT environment variable has not the right value on one of the build agents.

           

          With the tiny multi-configuration project attached, we build on two agents, corresponding to labels "db7" and "db9" (presumably two platforms on which we wish to run tests).

          Configuration matrix:

           

          Perforce settings:

           

          The Build step:

          p4plugin-test.xml

           

          The problem is easy to spot if you take a look at the console outputs. Here, project would fail on agent "db7" these are the relevant parts of the console output:

           

          P4: found 775729 revision in //jenkins-philippe2-msycmp517_nfs-p4plugin-test-platform-db7-1/...@774729,775729
          P4: builds: 775729
          [...]
          [db7] $ /bin/sh /tmp/jenkins7931966404345516969.sh
          P4_CHANGELIST=775729
          P4_CLIENT=jenkins-philippe2-msycmp504_nfs-p4plugin-test-platform-db9-8
          

           

          As you can see, the client automatically created by theP4  plugin is jenkins-philippe2-msycmp517_nfs-p4plugin-test-platform-db7-1 whereas the value of variable P4_CLIENT is jenkins-philippe2-msycmp504_nfs-p4plugin-test-platform-db9-8.

           

          After downgrading to 1.9.5, both names are identical, which is expected.

          Many thanks,

          Phil.

           

          Philippe Nobili added a comment - Hi Karl, Thanks for coming back to me on this. We created a tiny Jenkins project that demonstrates what is the problem is (attached here).    To make it short: P4_CLIENT environment variable has not the right value on one of the build agents.   With the tiny multi-configuration project attached, we build on two agents , corresponding to labels " db7 " and " db9 " (presumably two platforms on which we wish to run tests). Configuration matrix:   Perforce settings:   The Build step: p4plugin-test.xml   The problem is easy to spot if you take a look at the console outputs. Here, project would fail on agent " db7 " these are the relevant parts of the console output:   P4: found 775729 revision in //jenkins-philippe2-msycmp517_nfs-p4plugin-test-platform-db7-1/...@774729,775729 P4: builds: 775729 [...] [db7] $ /bin/sh /tmp/jenkins7931966404345516969.sh P4_CHANGELIST=775729 P4_CLIENT=jenkins-philippe2-msycmp504_nfs-p4plugin-test-platform-db9-8   As you can see, the client automatically created by theP4  plugin is  jenkins-philippe2-msycmp517_nfs-p4plugin-test-platform-db7-1  whereas the value of variable P4_CLIENT is  jenkins-philippe2-msycmp504_nfs-p4plugin-test-platform-db9-8 .   After downgrading to 1.9.5 , both names are identical, which is expected. Many thanks, Phil.  

          Karl Wirth added a comment -

          Hi pnobili,

          That's great thank you. I will try and reproduce this here and get back to you with next steps.

          Karl Wirth added a comment - Hi pnobili , That's great thank you. I will try and reproduce this here and get back to you with next steps.

          Karl Wirth added a comment -

          Hi pnobili ,

          Thanks again. I was easily able to reproduce it. Can you check if using the Jenkins variables in your script instead of P4_CLIENT works.

          For example, below the job runs on 'master', P4_CLIENT is wrong and mentions 'LinuxDesktop' but NODE_NAME is correct:

          P4: saving built changes.
          Found last change 10466 on syncID jenkins-NODE_NAME-JENKINS-64879-Matrix-Slaves-master-EXECUTOR_NUMBER
          ... p4 login -s +
          ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 +
          ... p4 info +
          ... p4 info +
          ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 +
          ... p4 login -s +
          ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 +
          ... p4 info +
          ... p4 info +
          ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 +
          ... done[master] $ /bin/sh -xe /tmp/jenkins711692634301571429.sh
          + hostname
          vm-kwirth-swarm201-xenial
          + grep P4
          + sort
          + env
          P4_CHANGELIST=10466
          P4_CLIENT=jenkins-LinuxDesktop-JENKINS-64879-Matrix-Slaves-LinuxDesktop-0
          + env
          + grep NODE_NAME
          NODE_NAME=master
          Finished: SUCCESS
          

          So can you please test if using 'jenkins-$NODE_NAME-$JOB_NAME-$EXECUTOR_NUMBER' instead of $P4_CLIENT works.

           

          Karl Wirth added a comment - Hi pnobili , Thanks again. I was easily able to reproduce it. Can you check if using the Jenkins variables in your script instead of P4_CLIENT works. For example, below the job runs on 'master', P4_CLIENT is wrong and mentions 'LinuxDesktop' but NODE_NAME is correct: P4: saving built changes. Found last change 10466 on syncID jenkins-NODE_NAME-JENKINS-64879-Matrix-Slaves-master-EXECUTOR_NUMBER ... p4 login -s + ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 + ... p4 info + ... p4 info + ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 + ... p4 login -s + ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 + ... p4 info + ... p4 info + ... p4 client -o jenkins-master-JENKINS-64879-Matrix-Slaves-master-1 + ... done[master] $ /bin/sh -xe /tmp/jenkins711692634301571429.sh + hostname vm-kwirth-swarm201-xenial + grep P4 + sort + env P4_CHANGELIST=10466 P4_CLIENT=jenkins-LinuxDesktop-JENKINS-64879-Matrix-Slaves-LinuxDesktop-0 + env + grep NODE_NAME NODE_NAME=master Finished: SUCCESS So can you please test if using 'jenkins-$NODE_NAME-$JOB_NAME-$EXECUTOR_NUMBER' instead of $P4_CLIENT works.  

          Hi Karl,

           

          Thanks for your feedback. That was the point not to hardwire this value in the build shell. But of course this would work, I don't even need to try  !

          We use P4_CLIENT variable precisely  to avoid polluting the build shell scripts with duplicated complex clients names, defined at project level... and subject to changes.

           

          From our understanding, this is a regression introduced after version 1.9.5 of the plugin where this variable  had the expected value. Being given the number of build shells and different client constructs we have in our ecosystem, such a change is not really an option for us.

           

          Philippe Nobili added a comment - Hi Karl,   Thanks for your feedback. That was the point not to hardwire  this value in the build shell. But of course this would work, I don't even need to try   ! We use P4_CLIENT  variable precisely  to avoid polluting the build shell scripts with duplicated complex clients names, defined at project level... and subject to changes.   From our understanding, this is a regression introduced after version 1.9.5 of the plugin where this variable  had the expected value. Being given the number of build shells and different client constructs we have in our ecosystem, such a change is not really an option for us.  

          Karl Wirth added a comment -

          Hi pnobili - Thanks. I have requested that the developers look at this as part of their next sprint.

          Karl Wirth added a comment - Hi pnobili - Thanks. I have requested that the developers look at this as part of their next sprint.

          Hi guys,

          Is a fix planned at some point about this issue ? This regression prevents us from upgrading to P4 plugin after 1.95 version, which has a few bugs of its own too, fixed in more recent ones...

           

          Many thanks for any feedback on this,

          Phil.

          Philippe Nobili added a comment - Hi guys, Is a fix planned at some point about this issue ? This regression prevents us from upgrading to P4 plugin after 1.95 version, which has a few bugs of its own too, fixed in more recent ones...   Many thanks for any feedback on this, Phil.

            Unassigned Unassigned
            pnobili Philippe Nobili
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: