Bugzilla – Full Text Bug Listing
| Summary: | virgo.osgi-test-stubs.snapshot VERY SLOW picking up latest git revision | ||
|---|---|---|---|
| Product: | Community | Reporter: | Steve Powell <zteve.powell> |
| Component: | CI-Jenkins | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | glyn.normington |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Steve Powell
Also virgo.gemini-web-container.snapshot has this polling log: ---8<-------- Started on Sep 15, 2010 6:01:16 AM Using strategy: Default [poll] Last Build : #86 [poll] Last Built Revision: Revision 5f28b4ba78d433cfeac33ead5cc66968dd1209b6 (origin/master) GitAPI created Fetching changes from the remote Git repositories Fetching upstream changes from git://git.eclipse.org/gitroot/gemini.web/org.eclipse.gemini.web.gemini-web-container.git [virgo.gemini-web-container.snapshot] $ git fetch -t git://git.eclipse.org/gitroot/gemini.web/org.eclipse.gemini.web.gemini-web-container.git +refs/heads/*:refs/remotes/gemini-web-container/* [virgo.gemini-web-container.snapshot] $ git ls-tree HEAD GitAPI created Fetching upstream changes from git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.virgo-build.git [virgo-build] $ git fetch -t git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.virgo-build.git +refs/heads/*:refs/remotes/gemini-web-container/* Polling for changes in [virgo.gemini-web-container.snapshot] $ git tag -l master [virgo.gemini-web-container.snapshot] $ git rev-parse origin/master Done. Took 2.5 sec No changes ------------- and yet changes were made to the git for this project as early as 2010-09-14 15:44:01 (BST == GMT +01:00) which is hours before this last poll. If the git polling mechanism is not working correctly, I am seriously considering pulling it. I'll do a quick bugzilla scan to see how much effort we've put into it so far. Sorry - we just can't sustain this. I would think that triggering of builds on source changes is a requirement of a ci-build server. (In reply to comment #3) > I would think that triggering of builds on source changes is a requirement of a > ci-build server. I agree. Manually kicking off CI builds is a non-starter. > I do not see this sort of lag for the other virgo jobs.
So there is either something different with this job, or with the repository it is accessing. Are there any timezone settings that could be affecting this?
OK. I think I might guess why this is not happening properly. The reason is that the polling log is checking the present workspace against the newly loaded one, and the configuration has changed to name the git clone directory differently since last time it was successfully built. (By the way, the last successful build was on build2 -- on the old hudson -- so the configuration will not match.) Polling is making assumptions about the old and new versions. Clearing the workspace should solve it. It ought to be possible for the polling plug-in merely to compare the commit SHA1s for the previous build with the latest head -- not downloading much at all -- and defer the down-loads until changes have been spotted. Wouldn't that be quicker, too? OK -- I'm going to clear the workspace to try to see if that 'cures' it. Yup -- that seems to be picking up the correct build -- we'll leave it half-an-hour to see if the polling gets it right. Polling looks ok -- I'll re-opn this if the polling fails to pick up the next change -- but I expect we're OK now. Thanks. |