|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
@Dean Yu here
Using @HEAD achieves the desired result of ensuring a checkout always grabs the latest revision, however the current SVN plugin has one glaring flaw with this - the "HEAD" revision number is not assigned to the Jenkins SVN_REVISION property / environment variable. Consequently you end up in a situation where your checkout is done at a certain revision and that revision is not easily addressable / referenced elsewhere in the project (e.g.: in the build label, for example). Similarly this makes it difficult, if not impossible, to propagate the same revision number to downstream jobs. Sure, you can configure the downstream jobs to use @HEAD as well, but this prevents you from ensuring a set of jobs runs against the same revision number.
Put another way, using this workaround is incompatible with the Parameterized Trigger Plugin because the revision number that gets propagated to downstream jobs is incorrect.