Jenkins JIRA | David Ehrenberger | 5 years ago
Click on the to mark the solution that helps you, Samebug will learn from it.
As a community member, you’ll be rewarded for you help.
  1. 0

    For some of our components, Jenkins build fails with the following error message in the console log: {noformat} 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( at hudson.scm.IntegrityCheckoutTask.invoke( at hudson.FilePath.act( at hudson.FilePath.act( at hudson.scm.IntegritySCM.checkout( at hudson.model.AbstractProject.checkout( at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout( at jenkins.scm.SCMCheckoutStrategy.checkout( at hudson.model.AbstractBuild$ at hudson.model.Run.execute( at at hudson.model.ResourceController.execute( at {noformat} 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 {noformat} hudson.scm.IntegrityCheckoutTask.invoke( {noformat} accesses the configuration path of a member in a prepared member list structure, which is null: {noformat} String configPath = memberInfo.get(CM_PROJECT.CONFIG_PATH).toString(); {noformat} The main cause seems to be speciality in integrity with the {{si projectinfo}} (this is the way currently implemented in the integrity plugin): {noformat} si projectinfo --project="d:/MKS/PlatformA/ComponentA/ModuleA/project.pj" --projectRevision="1.116" {noformat} Result: {noformat} 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 ... {noformat} 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: {noformat} si projectinfo --project="#p=d:/MKS/PlatformA/ProductA.pj#d=dev_(Rel7.8)#s=ComponentA/ModuleA/project.pj#forceJump=#b=1.114" {noformat} Result: {noformat} 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 ... {noformat} 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()}}: {noformat} 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); {noformat} 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.

    Jenkins JIRA | 3 years ago | Christian Bürenheide
  2. Speed up your debug routine!

    Automated exception search integrated into your IDE

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.NullPointerException

      No message provided

      at hudson.scm.CVSSCM$2.cleanup()
    2. Hudson
      1. hudson.scm.CVSSCM$2.cleanup(
      2. hudson.scm.CVSSCM$2.invoke(
      3. hudson.scm.CVSSCM$2.invoke(
      4. hudson.FilePath.act(
      5. hudson.FilePath.act(
      6. hudson.scm.CVSSCM.checkout(
      7. hudson.model.AbstractProject.checkout(
      8. hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(
      8 frames
    3. jenkins.scm
      1. jenkins.scm.SCMCheckoutStrategy.checkout(
      1 frame
    4. Hudson
      1. hudson.model.AbstractBuild$
      2. hudson.model.Run.execute(
      4. hudson.model.ResourceController.execute(
      5 frames