How would I fix this random failure when I have no real access to this machine?
All others I tried worked :/
Jacques
Le 26/06/2014 17:54, Adam Heath a écrit :
I'm the original author of the sophisticated UtilCache tests, btw.
On 06/26/2014 10:45 AM, Adam Heath wrote:
On 06/26/2014 04:54 AM, Jacques Le Roux wrote:
Le 05/02/2014 12:07, Jacques Le Roux a écrit :
On Wednesday, February 05, 2014 10:32 AM, pierre.sm...@gmail.com wrote
Jacques,
First you should answer the question for what we are using Buildbot.. Is it
for testing or for building?
It builds,tests and package nightly snapshots
http://ci.apache.org/projects/ofbiz/snapshots/
http://ci.apache.org/
http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-trunk
http://ci.apache.org/waterfall?show_events=false&branch=&builder=ofbiz-branch13
http://ci.apache.org/projects/ofbiz/logs/
With the appriopriate IVY configuration you can inject latest, latest
release, latest in version (e.g. 1.5.x), or whatever external (replacement
jar) to test.
How do you configure that?
Also I think that systematically using Yvy could prove to be difficult, we have
200+ external libs in OFBiz.
Not only to set it (but also to track which version to keep, etc.)
This said it could be useful for the main libs, but then I wonder if it's to
easier/more-simple to do it manually from time to time.
The advantages would be that we would be sure to have the last version, the drawback we need to check it compiles and tests when automatically
changed. With Buildbot, this should be OK.
Though at the moment, since we had to change the machine, the current Buildbot has a problem with the testBasicDisk test as shows the branch13
HTML report above.
So this is a question to All, could we not deconnect this test? It keeps
ransomy throwing false test alerts.
Because once on 2 testBasicDisk fails in Builbot I REALLY REALLY want to
disconnect it in trunk and all living releases, anyone against it?
Hrm? Then fix the random failures. Note how I just fixed the random failures
when run underneath java 1.7, because they were actually real failures.
Don't do this yet.
--
