You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-issues@apache.org by "Tony Stevenson (JIRA)" <ji...@apache.org> on 2012/06/21 10:04:42 UTC

[jira] [Commented] (INFRA-4949) Jenkins sometimes building against old svn revisions (Aries project)

    [ https://issues.apache.org/jira/browse/INFRA-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398270#comment-13398270 ] 

Tony Stevenson commented on INFRA-4949:
---------------------------------------

Holly, 

I see that the job is scheduled to run hourly, when the previous build failed.  That said I dont see any evidence here of it using ! HEAD. 
If you look in the changes tab, you will see that each build has several revisions associated with it.  i.e. build 1520 has 7 revs in it. You will see that several builds also contain the same revision.  This is because the project has not had a successful build with that revision included. That list looks perfectly fine to me.  

You have now had a successful build.  So lets see what happens going forward. 

The time on the hosts are in sync, as all our boxes are using ntpd. 
                
> Jenkins sometimes building against old svn revisions (Aries project)
> --------------------------------------------------------------------
>
>                 Key: INFRA-4949
>                 URL: https://issues.apache.org/jira/browse/INFRA-4949
>             Project: Infrastructure
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: Jenkins
>            Reporter: Holly Cummins
>
> Since the weekend, we've been seeing problems where Aries is sometimes building against HEAD, and sometimes against older revisions, with predictably chaotic results. 
> https://builds.apache.org/job/Aries/changes shows the problem, and I've included an excerpt below:
> #1519 (Jun 21, 2012 4:18:01 AM)
> [ARIES-860] Bring proxy.api bundle into line with proxy uber bundle in importing osgi framework at 1.5, rather than 1.6. Add tests to test proxying in both 3.5 and 3.7 equinox environments, and with the uber bundle and normal bundles. — cumminsh / ViewSVN
> #1516 (Jun 21, 2012 1:51:01 AM)
> [ARIES-860] Bring proxy.api bundle into line with proxy uber bundle in importing osgi framework at 1.5, rather than 1.6. Add tests to test proxying in both 3.5 and 3.7 equinox environments, and with the uber bundle and normal bundles. — cumminsh / ViewSVN
> [ARIES-859] Back out second version of ARIES 858 blueprint concurrency changes to try and improve build stability. — cumminsh / ViewSVN
> #1513 (Jun 20, 2012 10:51:01 PM)
> [SPI-Fly] Prevent registration of service properties starting with a dot '.'.
> This fixes an OSGi TCK failure. — davidb / ViewSVN
> Remove the register="*" functionality from the osgi.serviceloader capability as this functionality can be achieved by leaving out the directive.
> This fixes one failing test on the OSGi ServiceLoader Mediator CT.
> Also added a script to prepare and copy the ServiceLoader jar to the CT. — davidb / ViewSVN
> [ARIES-860] Bring proxy.api bundle into line with proxy uber bundle in importing osgi framework at 1.5, rather than 1.6. Add tests to test proxying in both 3.5 and 3.7 equinox environments, and with the uber bundle and normal bundles. — cumminsh / ViewSVN
> This post seems to describe our problem (we also had builds triggered when nothing in svn had changed) and suggests it could be a time mismatch issue: http://jenkins.361315.n4.nabble.com/Hudson-only-building-old-svn-revision-td3159740.html
> On the builds with older revisions, I'm seeing errors like the following:
> ERROR: Failed to update http://svn.apache.org/repos/asf/aries/trunk
> org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed
> 	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
> 	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
> 	at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
> 	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
> 	at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
> 	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
> 	at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
> 	at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557)
> 	at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414)
> 	at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324)
> 	at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
> 	at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
> 	at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
> 	at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
> 	at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
> 	at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315)
> 	at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295)
> 	at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391)
> 	at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136)
> 	at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
> 	at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
> 	at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
> 	at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
> 	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2180)
> 	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> 	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> 	at hudson.remoting.Request$2.run(Request.java:287)
> 	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:636)
> Caused by: svn: E175002: REPORT /repos/asf/!svn/vcc/default failed
> 	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
> 	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
> 	at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
> 	... 33 more
> no change for http://svn.apache.org/repos/asf/aries/trunk since the previous build

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira