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

SVN Plugin displays executing update for the correct path but uses last used path

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Windows Server 2008 R2
      Windows7 Slave
      SVN-Plugin 2.6

      The Jenkins Subversion Plug-in works great when using an specific repository URL, but it doesn't work well with parameterized paths.

      Our setup uses a job parameter to specify the SVN branch to use when doing any SVN operations. We currently have three branches: alpha, beta and Trunk. Depending on the order of the builds, the SVN update command fails in this case. We use separate workspace folders for each branch to make sure they are exclusive by using the parameter to select the proper workspace. When running a job with this setup, the job fails for upper branches since they receive updates from the lower branches if the lower branches were executed before.

      Parameter:

      Workspace Setup:

      SVN Plugin Setup:

      Scenario:

      1. Run SVN update for the alpha branch
      2. The Alpha job finishes successfully
      3. Run job for Beta branch
      4. Job runs and displays update for Beta branch
      5. There were no changes for the Beta branch, but changes are downloaded from the main Alpha branch (the latest revision - 37364 shown in the log) 
      6. Beta job fails to build because there are unexpected changes in the Beta branch folder

      Jenkins Log:

      I think the problem is because the SVN plugin is running an update on the wrong path even though it displays the right path in the log.

      e.g. displays beta, but it's really updating alpha since that was the last folder used.

      Just making sure the workspace and the path in the SVN Plugin settings are set correctly before the update should fix it.

        1. SVN Plugin.png
          SVN Plugin.png
          85 kB
        2. SVN Plugin - Log.png
          SVN Plugin - Log.png
          74 kB
        3. SVN Plugin - Parameter.png
          SVN Plugin - Parameter.png
          19 kB
        4. SVN Plugin - WS.png
          SVN Plugin - WS.png
          11 kB

          [JENKINS-45075] SVN Plugin displays executing update for the correct path but uses last used path

          Hector Santana created issue -
          Hector Santana made changes -
          Environment Original: Windows Server 2008 R2 Master (1.609.3)
          Windows7 Slave
          SVN-Plugin 2.6
          New: Windows Server 2008 R2
          Windows7 Slave
          SVN-Plugin 2.6
          Hector Santana made changes -
          Description Original: Our repositories make heavy use of [Subversion Externals|http://svnbook.red-bean.com/en/1.0/ch07s03.html], and we use a "post commit hook" to trigger builds.

          There are two ways to work with externals:
          - With a fixed revision (@-Syntax: https://subversion-server/repopath@1234)
          - With a floating revision (always up to date)

          The subversion-plugin detects correctly that those projects contains data from multiple SVN-Paths and tiggers the build also when an "imported" Repo sends a post-commit-hook.

          Here we observed the following problem:
          The post commit hook informs Jenkins about the number of the new SVN-revision. But the Subversion-Plugin use that Revision-Number for EVERY "SVN Update"-Command regardless of whether the path matches the project-repository or not.

          Case 1:
          Main-Repository - Head-Rev: 1000
          Imported Repository - Head-Rev. 154

          Someone commits rev 155 at the imported-Repo - Subversion tries to checkout Rev 155 from the Main-Repository!
          If the addressed Path in the main repository wasn't existing at rev 155 you get the following error msg:
          {code}
          ERROR: Failed to update https://subversion-server/repos/main-repo/trunk/referenced_projects
          org.tmatesoft.svn.core.SVNException: svn: E160005: Target path '/main-repo/trunk/referenced_projects' does not exist
          svn: E175002: REPORT of '/main-repo/!svn/vcc/default': 500 Internal Server Error
          {code}

          Case 2:
          Main-Repository - Head-Rev: 201
          Imported Repository - Head-Rev. 810

          Someone commits rev 811 at the imported-Repo - Subversion tries to checkout Rev 811 from the Main-Repository!
          {{Build is also broken with svn E160006: no such revision 811}}
          Hector Santana made changes -
          Description New: The Jenkins Subversion Plug-in works great when using an specific repository URL, but it doesn't work well with parameterized paths.
          Hector Santana made changes -
          Attachment New: SVN Plugin - Log.png [ 38599 ]
          Attachment New: SVN Plugin.png [ 38600 ]
          Hector Santana made changes -
          Description Original: The Jenkins Subversion Plug-in works great when using an specific repository URL, but it doesn't work well with parameterized paths. New: The Jenkins Subversion Plug-in works great when using an specific repository URL, but it doesn't work well with parameterized paths.

          Our setup uses a job parameter to specify the SVN branch to use when doing any SVN operations. We currently have three branches: alpha, beta and Trunk. Depending on the order of the builds, the SVN update command fails in this case. We use separate workspace folders for each branch to make sure they are exclusive by using the parameter to select the proper workspace.

          !SVN Plugin.png|thumbnail!

          Scenario:
           # Run SVN update for the alpha branch
           # The Alpha job finishes successfully
           # Run job for Beta branch
          Hector Santana made changes -
          Attachment New: SVN Plugin - Parameter.png [ 38601 ]
          Attachment New: SVN Plugin - WS.png [ 38602 ]
          Hector Santana made changes -
          Description Original: The Jenkins Subversion Plug-in works great when using an specific repository URL, but it doesn't work well with parameterized paths.

          Our setup uses a job parameter to specify the SVN branch to use when doing any SVN operations. We currently have three branches: alpha, beta and Trunk. Depending on the order of the builds, the SVN update command fails in this case. We use separate workspace folders for each branch to make sure they are exclusive by using the parameter to select the proper workspace.

          !SVN Plugin.png|thumbnail!

          Scenario:
           # Run SVN update for the alpha branch
           # The Alpha job finishes successfully
           # Run job for Beta branch
          New: The Jenkins Subversion Plug-in works great when using an specific repository URL, but it doesn't work well with parameterized paths.

          Our setup uses a job parameter to specify the SVN branch to use when doing any SVN operations. We currently have three branches: alpha, beta and Trunk. Depending on the order of the builds, the SVN update command fails in this case. We use separate workspace folders for each branch to make sure they are exclusive by using the parameter to select the proper workspace. When running a job with this setup, the job fails for upper branches since they receive updates from the lower branches if the lower branches were executed before.

          *Parameter:*

          !SVN Plugin - Parameter.png|thumbnail!

          *Workspace Setup:*

          !SVN Plugin - WS.png|thumbnail!

          *SVN Plugin Setup:*

          !SVN Plugin.png|thumbnail!

          *Scenario:*
           # Run SVN update for the alpha branch
           # The Alpha job finishes successfully
           # Run job for Beta branch
           # Job runs and displays update for Beta branch
           # There were no changes for the Beta branch, but changes are downloaded from the main Alpha branch (the latest revision - 37364 shown in the log) 
           # Beta job fails to build because there are unexpected changes in the Beta branch folder

          *Jenkins Log:*

          !SVN Plugin - Log.png|thumbnail!

          I think the problem is because the SVN plugin is running an update on the wrong path even though it displays the right path in the log.

          e.g. displays beta, but it's really updating alpha since that was the last folder used.

          Just making sure the workspace and the path in the SVN Plugin settings are set correctly before the update should fix it.

          Sounds similar to JENKINS-32582.

          Tomalak Geret'kal added a comment - Sounds similar to JENKINS-32582 .
          Hector Santana made changes -
          Link New: This issue relates to JENKINS-32582 [ JENKINS-32582 ]

            Unassigned Unassigned
            hsantana29 Hector Santana
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: