-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
1. Debian Stretch
2. Jenkins 2.319.3
3. p4-plugin 1.12.2
-
Powered by SuggestiMate
If "Lightweight checkout" is enabled for the "Pipeline script from SCM" the build fails with the following exception -
java.lang.NullPointerException
Caused: java.io.IOException
at org.jenkinsci.plugins.p4.scm.P4SCMFileSystem$BuilderImpl.build(P4SCMFileSystem.java:95)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:197)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:173)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:118)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:70)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:310)
at hudson.model.ResourceController.execute(ResourceController.java:99)
at hudson.model.Executor.run(Executor.java:432)
[JENKINS-68138] NPE for the Lightweight checkout with p4 plugin
Note - Tested on Ubuntu 20.04.1 and Jenkins 2.319.3 with P4-Plugin 1.12.2 and no error seen when lightweight checkout selected. Start of console log:
Started by user perforce Obtained Jenkinsfile from p4-JenkinsMaster-//depot/project1/main/... //${P4_CLIENT}/...jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER} [Pipeline] Start of Pipeline [Pipeline] node Running on Jenkins in /var/lib/jenkins/workspace/Jenkinsfile [Pipeline] { [Pipeline] stage [Pipeline] { (Test) [Pipeline] script [Pipeline] { [Pipeline] echo In script. [Pipeline] echo Sleeping... [Pipeline] checkout Executor number at runtime: 0 ... p4 login + ... p4 login -s +
I would be glad to share more information regarding this error, however either with the ALL level logging enabled for the p4-plugin it did not produce any useful output.
Just in case, while the perforce server itself is out of my control, the version in use is - Server version: P4D/LINUX26X86_64/2018.1/1957529 (2020/05/06).
To add some more details, the "Lightweight checkout" was working couple years back, but then we had to disable it due to the infinite number of clients like "Client jenkinsTemp-53c92eb6-1a82-4dcf-bf6c-5b965c6e35fa" it was generating. As long as we are now facing "WARNING: duplicate syncID found" in logs I was looking to give "Lightweight checkout" another try, but got this NPE instead.
Hi elxakpe,
It's less about the logs and more about how you have this setup.
(1) Are you using an SSL connection to Perforce?
(2) What happens if you recreate the credential and use that in the same job?
(3) If you create a simple test freestyle job that syncs files from Perforce and run the job does that work?
(4) What Jenkins plugins do you have installed?
(5) Please get me screenshots of the job definition from jenkins.
(6) If you have a Jenkinsfile please get me that file.
(7) What is the output for 'p4 protects -u USERNAME' where USERNAME is the user that is defined in the Jenkins credential?
Duplicate SyncIDs is usually a sign that you have a job that is polled but you have specified a variable in the workspace path. For example 'MY_BRANCH' in:
//depot/${MY_BRANCH}/... //${P4_CLIENT}/...
This is not valid because the polling mechanism needs to poll against a known path.
Hi Karl,
It looks to me that "Lightweight checkout" and regular checkout use different methods to access Perforce and this is likely to be the reason.
Addressing your questions:
(1) No we are not, this is unencrypted connection to Perforce.
(2) I am using the same Jenkins credentials to get pipeline script from Perforce and then in pipeline to checkout the source code from the same Perforce instance. Until "Lightweight checkout" is enabled for the Jenkins file, it works like a charm, however with "Lightweight checkout" enabled it fails while trying to get the Jenkinsfile from Perforce.
(3) There is no problem with syncing Jenkins file from Perforce in a regular way, i.e. without "Lightweight checkout".
(4) There is a variety. if you need a full list I can attach the one.
(5),(6) As per observation, the behavior does not depend on a Jenkins file content, cause the Jenkins file basically could not be fetched when "Lightweight checkout" is enabled. However I created the simple Jenkinsfile to illustrate the same. All requested information is attached.
(7) I cannot execute 'p4 protects -u' cause it requires root privileges at Perforce side, however if I execute 'p4 protect' under the Jenkins credentials account it returns a bunch of records for different folders.
I am getting duplicate SyncID for a different reason. In our Jenkins setup we have the master node and the execution node, the master node fetches Jenkinsfile from Perforce and in Jenkinsfile there is an instruction to run the build on the execution node. The problem happens due to in a build.xml file we are getting two identical SyncIDs for the Jenkinsfile fetch on the master node and on the execution node. With respect to SyncID uses workspace name and ignores any variable in the name except "{JOB_NAME}" I found no way to get different SyncIDs among two nodes.
For example below are two records created in build.xml for the test job I executed -
<entry>
<string>NODE_NAME</string>
<string>master</string>
</entry>
...
<client>jenkins-rnd-lightweight-test-script</client>
<syncID>jenkins-rnd-lightweight-test-script</syncID>
<entry>
<string>NODE_NAME</string>
<string>rkt-jenkins-packer-0</string>
</entry>
...
<client>jenkins-rnd-lightweight-test-script</client>
<syncID>jenkins-rnd-lightweight-test-script</syncID>
Thanks elxakpe,
I can't see anything wrong there.
For the duplicate SyncID try adding ${NODE_NAME} to the workspace name. For example for new jobs and in the docs:
we suggest:
'jenkins-${NODE_NAME}-${JOB_NAME}-${EXECUTOR_NUMBER}'
'-${EXECUTOR_NUMBER}' is not required if concurrent job execution is disabled. Also I personally user ${P4_CLIENT} in the workspace view. Just protects against making a typo in the client name:
//depot/code/... //${P4_CLIENT}/...
For the NPE please try this command at the command line:
p4 -u JENKINS_USER -p SERVER:PORT print //sw/PATH/Jenkinsfile # Replace PATH with the missing path from 'Not Working Job Definition.jpg'
This is the command Perforce runs to do the lightweight checkout instead of syncing the workspace on the master. If P4Java received a result it could not understand this may cause the problem.
Please also untick 'Quite Perforce messages' try the job again and ask your Perforce administrator to look in the P4D logs for the 'user-print' command sent by P4Jenkins to the server.
The error is occurring trying to build the file to retrieve:
so one other possibility. Are there standard ASCII characters in the depot path or is there anything high ascii such as language specific characters?
Regards,
Karl
Hi Karl,
(1) For the NPE, I executed the "p4 print" command from the master Jenkins node and looking at the output I can see no problem - the content of the Jenkinsfile is printed out. I have attached the screenshot for the same. Depot path contains only standard ASCII characters.
What is more interesting, I was capturing traffic over tcpdump while the job was triggered and with "Lightweight checkout" switched on it were no traffic towards Perforce server, i.e. it broke before it either established the connection to the Perforce server.
(2) For the duplicate SyncID, unfortunately it does not work this way. Here is an extract from the Perforce guide (https://www.perforce.com/manuals/jenkins/Content/P4Jenkins/pipeline-script-setup.html#Polling)
... if the client Workspace name contains any of the following variables their values will be ignored when determining the syncID:
- NODE_NAME (which might change between slaves)
- BUILD_NUMBER (which changes for each build)
- EXECUTOR_NUMBER (changes based on the execution thread)
)
And it really works this way, so when I used jenkins-${NODE_NAME}-${JOB_NAME}-script name to fetch the Jenkinsfile I got two identical SyncIDs in build.xml that looked as -
jenkins-NODE_NAME-rnd-lightweight-test-script
i.e. for the Jenkinsfile SyncID the name of the variable was used instead of the variable value.
elxakpe - Thanks for reporting this. Please email support@perforce.com
so I can ask you some details about your Perforce servers that you don't want to share on this public forum.