Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Hudson builds fail on bogus time-out error

Hi, Céline,

Indeed, not difficult, but not quite so straightforward as using variables:  the *.tpd/*.target files don’t support variable substitution for this purpose, but it was easy enough to use Ant to automate a transformation of the *.target files.  Also, it was easy enough to have the releng POM detect automatically whether it the build is running on the Papyrus-RT HIPP or some other environment, using profiles to choose between the Eclipse-local or portable variant of the target.

This does turn out to have drastically improved build times when HTTP responses from download.eclipse.org were slow, so that’s good.

See review 82547 (bug 504102) for details.

Christian


On 5 October, 2016 at 11:03:08, Céline JANSSENS (celine.janssens@xxxxxxxxxxx) wrote:

+1. 

 

That can be done into the TP files with a specific property like in Papyrus : transfer.protocol=”file” or “http”

By default it would be “http”, and in the jobs, we can override it to “file”.

 

It seems not too difficult to put in place.

 

Céline

 

 

De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mercredi 5 octobre 2016 16:57
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Hudson builds fail on bogus time-out error

 

Hi,

 

Now it looks like we just have some kind of severe performance problem in accessing download.eclipse.org via HTTP:  fetching the metadata from p2 repositories hosted there is extremely slow.  I’m working on generation of targets localized for use on Eclipse.org that access the downloads via the local filesystem, as is done in Papyrus.  The build would automatically detect when it is running in the HIPP on Eclipse.org to activate that option.

 

Cheers,

 

Christian

 

 

On 5 October, 2016 at 08:47:30, Christian Damus (give.a.damus@xxxxxxxxx) wrote:

Hi, Team,

 

It appears that we now have Gerrit builds failing on a time-out error accessing the latest successful build results of the Papyrus Developer component:

 

[ERROR] Failed to resolve target definition /jobs/genie.papyrus-rt/Papyrus-RT-Gerrit-Core/workspace/source/org.eclipse.papyrusrt.targetplatform/papyrusrelease/org.eclipse.papyrusrt.targetplatform.neon.rt.included/org.eclipse.papyrusrt.targetplatform.neon.rt.included.target: Failed to load p2 metadata repository from location http://hudson.eclipse.org/papyrus/job/Papyrus-Neon-Developer/lastSuccessfulBuild/artifact/repository/: Unable to read repository at http://hudson.eclipse.org/papyrus/job/Papyrus-Neon-Developer/lastSuccessfulBuild/artifact/repository/content.xml. Connect to hudson.eclipse.org:80 timed out -> [Help 1]
org.apache.maven.MavenExecutionException: Failed to resolve target definition /jobs/genie.papyrus-rt/Papyrus-RT-Gerrit-Core/workspace/source/org.eclipse.papyrusrt.targetplatform/papyrusrelease/org.eclipse.papyrusrt.targetplatform.neon.rt.included/org.eclipse.papyrusrt.targetplatform.neon.rt.included.target: Failed to load p2 metadata repository from location http://hudson.eclipse.org/papyrus/job/Papyrus-Neon-Developer/lastSuccessfulBuild/artifact/repository/
        at org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:100)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:266)
        ...
Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to hudson.eclipse.org:80 timed out
        at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:119)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
   ...

 

 

I don’t think that anything has changed in the Papyrus builds that could cause this.  Is it possible that today's plug-in installations and/or restart of the Papyrus-RT HIPP could have broken HTTP connections to the other HIPPs at eclipse.org?

 

And I don’t suppose it will be just the Gerrit builds that fail, but the main component and product builds, too, because they all use the same target-platform files.  Papyrus has two forms of every TP, one using HTTP access and one using local disk access for use on the Hudson build servers.  Should we be doing the same?  I have no trouble accessing the required resources in the Papyrus Hudson instance from home; it’s only our builds that are timing out.

 

This would be another thing to account for in the single-sourcing of TPs for the build and Oomph setups for the developers.

 

Thanks,

 

Christian

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

Back to the top