|
||||||||
|
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.
Searching for changes on a tag in a multi-module setup is not as easy at it sounds. Consider the following:
1. A user checks in changes on a branch/head (we may or may not be monitoring this location, it doesn't really matter). At the same time they check in changes on a branch/head we are monitoring.
2. Polling picks up these changes and a build is scheduled
3. The build completes so the last checked timestamp is rolled forward to the build's start time.
4. The user changes the existing tag to point to a new version of the file. Since tagging doesn't create any commit messages and the commit messages for the changed files have already been seen in the last build, no message appears in rlog for the files changed in the tag. Polling therefore doesn't see a change so doesn't schedule a build.
It would be possible to pick-up changes on a tag if the changes and re-tag happen in the same polling cycle, but there's no way to guarantee this especially if polling is scheduled to happen frequently. I can apply such a change before the next release, although this could result in users who change tag contents seeing inconsistent polling behaviour depending on how their commits compare to the polling cycle.
To try and pick-up all situations where a tag would change, polling would have to be done using the full repository history - not just changes between the last build and current poll. This isn't particularly practical as frequently changed repositories are going to have a large change-log so require a lot of time, memory and processing cycles to retrieve and parse.