-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Jenkins ver. 1.546,
integrity-plugin 1.20
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.