Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-56522

SVN changes are not passed in the right manner to the incremental build option

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      CentOS Linux release 7.0.1406 x86_64
      OpenJDK 1.8.0_181-b13
      Jenkins ver. 2.150.3
      Maven Integration plugin 3.2
      Subversion Plug-in 2.12.1
    • Similar Issues:

      Description

      I am facing a issue where the incremental build option is not working correctly / not building the changes for a maven project.

      The basic setup is that the complete branch is checked out from SVN, then a groovy script is run adding all the checked modules to a pom.xml. (see sample pom.xml; note: the projects which contain the changes are present in the pom.xml generated) 

      Then I would expect the incremental build to put the changed projects after the -pl option of the maven command - but this is not working as expected. I did not find a pattern yet on how this project list is populated. 

      Executing Maven: -B -f /var/lib/jenkins/jobs/MVNBuildAllModules-4.0.0/workspace/BuildAllPomScript/pom.xml -amd -pl com.company:CHANGED_Moduleclean deploy -U -Djarsigner.skip=true -DskipTests-x

      Consider the following log-example:

      [EnvInject] - Loading node environment variables.
      Building remotely on slave-name in workspace /var/lib/jenkins-slave/remote-root/workspace/MVNBuildAllModules-TRUNK
      Updating http://pathfinder/svn/company/trunk at revision '2018-12-18T19:36:04.411 +0100'
      U ProjectS/src/main/java/com/company/packagename/ChangedJavaClass1.java
      U ProjectH3W/src/main/java/com/company/packagename/ChangedJavaClass2.java[...][MVNBuildAllModules-TRUNK] $ groovy /var/lib/jenkins-slave/remote-root/workspace/MVNBuildAllModules-TRUNK/hudson1813316916530204030.groovy
      Adding module:ProjectA
      Adding module:ProjectB
      Adding module:ProjectC[...]
      Adding module:ProjectS
      Adding module:ProjectH3W
      [...]
      Adding module:ProjectX
      Adding module:ProjectY
      Adding module:ProjectZ
      [...]Executing Maven: -B -f /var/lib/jenkins-slave/remote-root/workspace/MVNBuildAllModules-TRUNK/BuildAllPomScript/pom.xml
      -amd -pl com.company:ProjectX, com.company:ProjectA, com.company:ProjectZ clean deploy -U -Djarsigner.skip=true -DskipTests_x

        

      Adding module: ... output comes from the groovy script which then creates a <module>../ProjectXYZ</modules> entry in the pom.xml

      Assume that ProjectX is dependent on ProjectS and ProjectZ is dependent on ProjectH3W. I would now expect jenkins/maven to build ProjectS, ProjectH3W and als the ones that are dependent (in this short example: ProjectX and ProjectZ) but the -pl option does not necessarily contain all the projects which are changed and also contains some other random projects, which are not in the changelist of SVN.

      I assume there is a bug in the plugin which is responsible for adding the changes to the -pl option.

        Attachments

          Activity

          Hide
          k_klemens K K added a comment -

          Through printing out the change set with a groovy script and enabling FINER debugging log on jenkins, I guess I found the the cause for the problem. 
          What I think we are doing different (than someone lets say using GIT and checking out each module at its own) is that we just check out the whole branch containing all the modules.

          The change set contains some paths like this: 
          /branches/4.0.0/ProjectA/[...]
          Then the mavenplugin (class MavenModuleSetBuild Method getChateSetFor(finale MavenModule mod)) tries to incrementally build the project and in the Method isDescendantOf(String path, MavenModule mod) it uses Java's String startsWith to compare both the MavenModule name (which according to the Debug output is ProjectA) with the affectedPath which is "/branches/4.0.0/ProjectA" and therefore the incremental build option will not work.

           

          I also tried using another project layout where there is a root project and in this folder all the modules are contained, which as well did not work out correctly when commiting to the repository. 
          After trying to understand the code, in my opinion there should be an option which allows to specify where the check for the affectedPaths should start. (e.g. a option to ignore /branches/4.0.0/ for the affectedPaths of the changes set) 

          Show
          k_klemens K K added a comment - Through printing out the change set with a groovy script and enabling FINER debugging log on jenkins, I guess I found the the cause for the problem.  What I think we are doing different (than someone lets say using GIT and checking out each module at its own) is that we just check out the whole branch containing all the modules. The change set contains some paths like this:  /branches/4.0.0/ProjectA/ [...] Then the mavenplugin (class MavenModuleSetBuild Method getChateSetFor(finale MavenModule mod)) tries to incrementally build the project and in the Method isDescendantOf(String path, MavenModule mod) it uses Java's String startsWith to compare both the MavenModule name (which according to the Debug output is ProjectA) with the affectedPath which is "/branches/4.0.0/ProjectA" and therefore the incremental build option will not work.   I also tried using another project layout where there is a root project and in this folder all the modules are contained, which as well did not work out correctly when commiting to the repository.  After trying to understand the code, in my opinion there should be an option which allows to specify where the check for the affectedPaths should start. (e.g. a option to ignore /branches/4.0.0/ for the affectedPaths of the changes set) 

            People

            • Assignee:
              Unassigned
              Reporter:
              k_klemens K K
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: