-
Bug
-
Resolution: Unresolved
-
Major
-
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:
- 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:
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.
- relates to
-
JENKINS-32582 List Subversion Tags default tag fails for Poll SCM trigger
-
- Open
-
[JENKINS-45075] SVN Plugin displays executing update for the correct path but uses last used path
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 |
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}} |
Description | New: The Jenkins Subversion Plug-in works great when using an specific repository URL, but it doesn't work well with parameterized paths. |
Attachment | New: SVN Plugin - Log.png [ 38599 ] | |
Attachment | New: SVN Plugin.png [ 38600 ] |
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 |
Attachment | New: SVN Plugin - Parameter.png [ 38601 ] | |
Attachment | New: SVN Plugin - WS.png [ 38602 ] |
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. |
Link | New: This issue relates to JENKINS-32582 [ JENKINS-32582 ] |
Sounds similar to JENKINS-32582.