when using Jenkins for continuous integration, the SVN plugin that encountered Jenkins did not update to the latest code situation.
For example, using Jenkins to update code immediately after the code was submitted, the code that was just submitted was not updated to the old version of the code that was updated.
Check online related content, there is a saying: Jenkins server time and SVN server time is not consistent, Jenkins's SVN plugin is used to download the time tag, rather than take the head, so if the SVN server commit code time than the current time Jenkins, The code will not be updated. The problem solved is as long as the Jenkins server time is set to the same as the SVN server time.
Yes, it solves the problem, but Jenkins's SVN plugin is a timestamp-related SVN revision?
To view the build log for a Jenkins job, when you update the code with the SVN plugin, the log is as follows:
Updating Svn://repository_path at revision ' 2015-08-06t08:48:12.490 +0800 'As can be seen from the above, the corresponding revision of this build is indeed the build timestamp.
So, can you let Jenkins's SVN plugin update the code to set revision to head? The answer is yes, in the SVN url plus @head suffix, Jenkins's SVN plugin is to support this. After the SVN url plus the @head suffix, the log output after the Jenkins job is built is as follows:
Updating svn://repository_path@HEAD at revision HEAD And this ensures that the updated code is up-to-date and will not be affected by the time difference between the Jenkins server and the SVN server. Note: Head is the SVN revision keyword that represents the latest version in the repository.
Check out the SVN checkout/update help documentation via SVN assist, about the revision option, as follows:
As seen above, the revision option is: Number (revision number), ' {' Date '} ' (timestamp), and Revison keyword (HEAD, BASSE, COMMITTED, PREV).
By looking at the source code of the Jenkins SVN plugin:
Workspaceupdater.java part of the source code is as follows:
From the comments you can see the strategy for getting SVN revision://For the SVN revision, we'll use the first off:
-a @NNN suffix of the SVN URL
-A value found in a revisionparameteraction
-the revision corresponding to the build timestamp
As you can see, for SVN revision, get the following priority:-The @nnn suffix of the svn url (@NNN is the value in SVN revision)-Revisionparameteraction, Revisionparameteraction is primarily used for parametric construction, maintaining revision consistency between two builds-the corresponding revision of the build timestamp
Before, the comment was a little small error, and a pull request was submitted to fix the following: https://github.com/jenkinsci/subversion-plugin/pull/130
Reference: http://blog.chinaunix.net/uid-26598889-id-3402223.html http://www.tuicool.com/articles/B326v27 https:// Wiki.jenkins-ci.org/display/jenkins/subversion+plugin Https://github.com/jenkinsci/subversion-plugin
Brief analysis of Jenkins ' SVN plugin not updated to the latest code
