-
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