Am 09.06.2010 11:57, schrieb Oberhuber, Martin:
Hi Eike,
do you re-use the same
repository location to push your CDO updates?
Yes, indeed! I've spent the last days to come up with an own
aggregation for several types of important builds (I, R, S, M) but it's
not easy for me because alll these things like p2 details and b2
aggregator are completely new to me.
For the most recent contribution I've chosen a different repo location
already. Let's hope that this fixes the issue.
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.
I see. Thanks for the info ;-)
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.
I hope that I can fix and automate all this for Indigo...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|