[JIRA] [clearcase] (JENKINS-17882) ClearCase polling not effective for MultiSite
SCM/JIRA link daemon resolved JENKINS-17882 as Fixed ClearCase polling not effective for MultiSite Change By: SCM/JIRA link daemon (07/Feb/14 3:54 PM) Status: Open Resolved Resolution: Fixed 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.
[JIRA] [clearcase] (JENKINS-17882) ClearCase polling not effective for MultiSite
SCM/JIRA link daemon commented on JENKINS-17882 ClearCase polling not effective for MultiSite Code changed in jenkins User: Vincent LATOMBE Path: src/main/java/hudson/plugins/clearcase/AbstractClearCaseScm.java http://jenkins-ci.org/commit/clearcase-plugin/b9a6e7a2a911f7cfc0aafa9344ab3735f227353c Log: FIXED JENKINS-17882 Disable comparison with previous polling as soon as multi-site poll buffer is non-null. Otherwise we might miss some commits. Compare: https://github.com/jenkinsci/clearcase-plugin/compare/cf9e0b691520...b9a6e7a2a911 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.
[JIRA] [clearcase] (JENKINS-17882) ClearCase polling not effective for MultiSite
Pawel Josefsson commented on JENKINS-17882 ClearCase polling not effective for MultiSite Handling of epoch numbers could adress this issue. I'm not sure the problem is possible to solve in a 100% bullet proof way since ClearCase doesn't have an absolute ID of what you see in a view (regardless of dyn or snapshot). workaround is to use labels and locks which are replicated if I recall things correctly. Master build site have to create baseline of locked labels from local and remote sites to construct a config_spec and manufacture a change report, basically you won't get any help from the CC plugin someone might have better idea or tricks... Not sure if UCM works better... 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.
[JIRA] [clearcase] (JENKINS-17882) ClearCase polling not effective for MultiSite
klou created JENKINS-17882 ClearCase polling not effective for MultiSite Issue Type: Bug Affects Versions: current Assignee: Vincent Latombe Components: clearcase Created: 07/May/13 7:46 AM Description: I'm not 100% sure but I think currently the polling for VCS changes for the build trigger currently uses a (UTC) date/time reference -since which is the time stamp of the last polling (not the last executed build). Unfortunately this seems not compatible with ClearCase MultiSite. ClearCase MultiSite does a replication between servers at different locations at fixed intervals (for example once each hour). This means a change a location X will, in worst case, be visible at location Y only after 1 hour. But the time stamp of the change will still be the original one (i.e. when the check-in was actually done, in example a time 1 hour ago). Thus, with the time reference to last poll most of the changes coming in from a remote server will not be considered by VCS polling. Example flow (VCS polling done at a H/10 * * * * schedule at location) Location Time Action X 10:00 Checkin FILE-1 Y 10:04 VCS Poll (-since 9:54). No change seen as no MultiSite Sync was done. X 10:07 VCS Poll (-since 9:57). Change FILE-1 seen. Build at location X triggered. X and Y ... Several further VCS polls. No changes detected. Y 10:54 VCS Poll (-since 10:44). No change seen as no MultiSite Sync was done. X-Y 10:58 ClearCase MultiSite Replication performed and completed. Y 11:04 VCS Poll (-since 10:54). PROBLEM Change of FILE-1 at 10:00 is now replicated but not seen due to -since 10:54 but the change actually is recorded in ClearCase with time stamp 10:00. Environment: Jenkins 1.514 on Win7-64, Slaves on Win7-64, all on JRE 1.7.0_07 64bit ClearCase Plugin v 1.3.14. Slave nodes on remote locations all around the world accessible via WAN. ClearCase MultiSite for remote locations. Project: Jenkins Labels: clearcase multisite Priority: Major Reporter: klou 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.
