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
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