[JIRA] [integrity-plugin] (JENKINS-21350) NullPointerException during checkout on variant projects where the original project has been moved.

Mon, 13 Jan 2014 05:11:10 -0800

Issue Type: Bug Bug
Affects Versions: current
Assignee: Cletus D'Souza
Components: integrity-plugin
Created: 13/Jan/14 1:10 PM
Description:

For some of our components, Jenkins build fails with the following error message in the console log:

Preparing to execute si projectinfo for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj
Preparing to execute pre-build si checkpoint for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj
Successfully executed pre-build checkpoint for project #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj, new revision is 1.115
Preparing to execute si viewproject for #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.115
Checkout directory is /jenkins/mks/dev_Rel7.8/ComponentA/ModuleA
A clean copy is requested; deleting contents of /jenkins/mks/dev_Rel7.8/ComponentA/ModuleA
Populating clean workspace...
FATAL: null
java.lang.NullPointerException
	at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:277)
	at hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:24)
	at hudson.FilePath.act(FilePath.java:914)
	at hudson.FilePath.act(FilePath.java:887)
	at hudson.scm.IntegritySCM.checkout(IntegritySCM.java:790)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1415)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
	at hudson.model.Run.execute(Run.java:1678)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:231) 



The build fails under those circumstances:


    
	
  • The affected integrity project is a variant (development path) project.
    • 
	
  • The original project of that variant project has been moved.
    • 





In this case, the module 



d:/MKS/PlatformA/OldComponent/ModuleA (MKS project name: d:/MKS/PlatformA/OldComponent/ModuleA/ModuleA.pj)



has been moved to     



d:/MKS/PlatformA/ComponentA/ModuleA (new MKS project name: d:/MKS/PlatformA/ComponentA/ModuleA/project.pj)



Problem analysis:



The code line at





hudson.scm.IntegrityCheckoutTask.invoke(IntegrityCheckoutTask.java:277)






accesses the configuration path of a member in a prepared member list structure, which is null:





String configPath = memberInfo.get(CM_PROJECT.CONFIG_PATH).toString();






The main cause seems to be speciality in integrity with the si projectinfo (this is the way currently implemented in the integrity plugin):





si projectinfo --project="d:/MKS/PlatformA/ComponentA/ModuleA/project.pj" --projectRevision="1.116"






Result:




Build Project Name: d:/MKS/PlatformA/OldComponent/ModuleA/ModuleA.pj
 Server: ...
 Configuration Path: #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.116
 ...






Here we get back the old project name (which was valid before the move). 

But when we execute project info using the configuration path we get the 

new project name as a result:





si projectinfo --project="#p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.114"






Result:




Build Project Name: d:/MKS/PlatformA/ComponentA/ModuleA/project.pj
 Server: ...
 Configuration Path: #p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.114
 Revision: 1.114
 ...





The problem is that during IntegrityCMProject.parseProject(), where the project including it's members is parsed, the project name that comes with the member infos is matched against that name (using Hashtable<String, String> pjConfigHash) to find out the configuration path for each member. Here the "new name" is matched against the "old name" so that the config 

path stays null.



My proposal for a workaround would be to change the implementation to the second way in IntegritySCM.checkout():





Command siProjectInfoCmd = new Command(Command.SI, "projectinfo");

//instead of
//siProjectInfoCmd.addOption(new Option("project", siProject.getProjectName()));  
//siProjectInfoCmd.addOption(new Option("projectRevision", chkpt));

//we would use 
siProjectInfoCmd.addOption(new Option("project", siProject.getConfigurationPath() + "#forceJump=#b=" + chkpt));  

Response infoRes = api.runCommand(siProjectInfoCmd);






We have this approach in use for our projects and it solves that problem. It would be nice if we could have the fix/workaround in one of the next ptc-integrity plugin revisions. I will provide a pull request with that solution.
Due Date: 13/Jan/14 12:00 AM
Environment: Jenkins ver. 1.546,
integrity-plugin 1.20
Project: Jenkins
Priority: Major Major
Reporter: Christian Bürenheide
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to