Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] Status and Outlook for RC4 +2 day
Hi Eike,
 
do you re-use the same repository location to push your CDO updates?
 
Then it could perhaps happen that the aggregator takes not only your main repo into account but
also any mirrors it finds ... and one of the mirrors might have stale data ... can happen when
you rebuild the same bundle ID at a different date.
 
On my project, I've been mitigating this by using 2 repo locations (3.2milestones and 3.2interim)
and switching between them on every contribution.
 
Another possible fix might be contributing a "file:/" URL rather than http:/
 
But that's all just a hunch, I don't know how the aggregator works internally.
 
Thanks,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
direct +43.662.457915.85  fax +43.662.457915.6
 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Eike Stepper
Sent: Wednesday, June 09, 2010 11:45 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Status and Outlook for RC4 +2 day

Hi,

I noticed this in the console log of https://build.eclipse.org/hudson/job/helios.runAggregator/188/consoleFull :

     [exec] org.eclipse.core.runtime.CoreException: Unable to mirror artifact osgi.bundle,org.eclipse.emf.cdo.server.hibernate.source,3.0.0.v20100601-0658 from repository http://download.eclipse.org/modeling/emf/cdo/updates/3.0: MD5 hash is not as expected. Expected: 77d7dc65157974111df5e186ffa6a0b7 and found 4c06002c379daa39cbc683332774eca5.
     [exec] 
     [exec] org.eclipse.core.runtime.CoreException: Unable to mirror artifact osgi.bundle,org.eclipse.net4j.db.hsqldb.source,3.0.0.v20100520-0807 from repository http://download.eclipse.org/modeling/emf/cdo/updates/3.0: MD5 hash is not as expected. Expected: 91b910228c3055b5487a47db216cc627 and found 9a0820e248da62eba656644c5473f081.
     [exec] 
     [exec] org.eclipse.core.runtime.CoreException: Unable to mirror artifact osgi.bundle,org.eclipse.net4j.util.ui.source,3.0.0.v20100519-1647 from repository http://download.eclipse.org/modeling/emf/cdo/updates/3.0: MD5 hash is not as expected. Expected: a6678b841a8192cd8a0b184df96a7884 and found a79dc2e87d274053cc41bb3eb0dd65bf.

Did I cause this and what does it mean?

I've already finished a new build and I did contribute it again to Helios. It should be picked up by aggregation #190 in a couple of minutes...

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Am 09.06.2010 08:13, schrieb Eike Stepper:
Am 09.06.2010 00:46, schrieb David M Williams:

Good news and bad. I did promote a build in early afternoon (Eastern time) but, there has
been a number of contributions since, yet the build has been prevented from getting very far by, for several hours, all due to

requires 'org.eclipse.net4j.sdk.feature.group 3.0.0.v20100608-1558' but it could not be found
This is really strange (at least for me). After analyzing a long time what might have happened, I come to the conclusion that it's related with using the new build2 slave. Usually I take the feature versions for my contribution from this page: https://build.eclipse.org/hudson/job/emf-cdo-integration/lastSuccessfulBuild/artifact/result/site.p2/index.html . These versions *are* correct.

My promotion mechanism used to copy the content of this disk folder: /opt/users/hudsonbuild/.hudson/jobs/emf-cdo-integration/workspace/result/site.p2

But now I realize that this folder contains old content. I suspect this is because I've built on build2 instead of the master. After searching for a long time I've found the correct and newest artifacts here: /opt/users/hudsonbuild/.hudson/jobs/emf-cdo-integration/builds/2010-06-08_12-58-26/archive/result/site.p2

Is there a way to refer to the latest build artifacts on (a) disk that does neither require to know what the build-id is nor on what node the build was done?

For now I replaced the wrong old artifacts with the correct new ones. The next Helios aggregation should pick them up.



Mail has been sent to
EMF CDO Build Team <stepper@xxxxxxxxxx>
but I have heard no response yet.

How does this happen? Do people work real hard
Yes, 14 hours yesterday until 8pm my time.

to make a hurry up a contribution
No hurry was involved.

and then leave work before seeing if it succeeded?
I even used my iPhone to check the aggregation from time to time. But as you can see from the timestamps my contribution missed aggregation #176 by 2 minutes and was picked up ~2 hours later by #177. At that time I was already unconcious. Sorry for that and thank you for temporarily reverting my contribution.

Guess it goes without saying too much hurry slows everyone down.
But, who am I to judge ....

 ... WTP will be a bit late with final RC4 contribution.
We do have a very nearly final build/contribution at

http://download.eclipse.org/webtools/downloads/drops/R3.2.0/S-3.2.0RC4-20100608132130/

(made "invisible" on downloads page, unless you go to direct URL).
but there was a late breaking (important) doc contribution that I'd like to get into our final RC4 build,
since I fully expect that to be our last for this release. Apologies for the delay ... it will likely be done
shortly after midnight (the very beginning of RC4 +3 day (the bad news here is that I was thinking all
day that webtools was +3, until right after deciding to do one last build and then remembered we are +2  :(

Remember that at EOD Wednesday (after RC4) I'll turn off auto builds and any further contributions will take
a request and justification for an exception to our final "quiet week".

Thanks all, 


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top