Hi, I don't think the 2 approaches exclude each other :) If we do manage to find a sponsor it doesn't mean that we shouldn't take the time to clean our builds, and take responsibility for some of the failures.
I don't mean to go off topic here but the latest error is introduced by OAK-2220 [0]. best, alex [0] Running org.apache.jackrabbit.oak.osgi.OSGiIT [main] INFO org.ops4j.pax.exam.spi.DefaultExamSystem - Pax Exam System (Version: 3.4.0) created. [main] INFO org.ops4j.pax.exam.junit.impl.ProbeRunner - creating PaxExam runner for class org.apache.jackrabbit.oak.osgi.OSGiIT [main] INFO org.ops4j.pax.exam.junit.impl.ProbeRunner - running test class org.apache.jackrabbit.oak.osgi.OSGiIT ERROR: Bundle org.apache.jackrabbit.oak-jcr [20] Error starting file:/home/buildslave3/slave3/oak-trunk/build/oak-it/osgi/target/test-bundles/oak-jcr.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.jackrabbit.oak-jcr [20]: Unable to resolve 20.0: missing requirement [20.0] osgi.wiring.package; (osgi.wiring.package=org.apache.jackrabbit.oak.plugins.atomic)) org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.jackrabbit.oak-jcr [20]: Unable to resolve 20.0: missing requirement [20.0] osgi.wiring.package; (osgi.wiring.package=org.apache.jackrabbit.oak.plugins.atomic) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974) at org.apache.felix.framework.Felix.startBundle(Felix.java:2037) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304) at java.lang.Thread.run(Thread.java:662) On Tue, Feb 3, 2015 at 4:30 PM, Michael Dürig <[email protected]> wrote: > > Hi, > > Both our buildbot instances [1, 2] fail most of the time. Similar for > Travis I think. > > I tried to keep the builds green in the past but the effort is just too > high. IMO the main problem is the bad signal to noise ratio. Many failures > are platform related in one way or another, which means we are basically > blind for real failures. > > I see basically two approaches to improve the situation: > > 1. Move to a more stable (commercial?) CI. In this case we need to find a > sponsor (Adobe, hint hint). > > 2. Split the build in smaller units (e.g. unit tests, IT per fixture, > extra modules like cold standby, OSGI stuff and so on). In this case we > need to find owners taking responsibility for keeping individual CIs green. > > WDYT? > > Michael > > [1] http://ci.apache.org/builders/oak-trunk > [2] http://ci.apache.org/builders/oak-trunk-win7 >
