Release build failed

0 views
Skip to first unread message

Robert LaRubbio

unread,
Sep 21, 2012, 4:45:14 PM9/21/12
to motec...@googlegroups.com
Lesson learned, I should have looked and verified the platform build was green before branching for the release build.  Anyway does anyone know if these failures are an issue with the build server, or legitimate test errors:


-Rob

Akula Srinivasa Manohar

unread,
Sep 24, 2012, 2:56:46 AM9/24/12
to motec...@googlegroups.com

These failures are because of design doc changes in the flowsession db. I think we use the same box to run 0.12 and 0.13 builds which have different versions for flowsession document. I've added a fix in my current story to delete the entire db in @After and to have it created it in @Before. Maybe we can move this to our SpringIntegrationTest superclass.

--
You received this message because you are subscribed to the Google Groups "MoTeCH Developer" group.
To post to this group, send email to motec...@googlegroups.com.
To unsubscribe from this group, send email to motech-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Jakub Sławiński

unread,
Sep 24, 2012, 9:47:20 AM9/24/12
to motec...@googlegroups.com

Hi,

I committed one small fix and merged a couple of changes to master:

* http://review.motechproject.org/#/c/355/
* http://review.motechproject.org/#/c/354/

What is the status of release? Where should I move the following trello
cards (there is only Release 0.13 list available at the moment):

* https://trello.com/c/bPnK4SmS
* https://trello.com/c/pksVnlOs
* https://trello.com/c/54li7PSW


Regards,
Jakub.

Robert LaRubbio

unread,
Sep 24, 2012, 10:08:54 AM9/24/12
to motec...@googlegroups.com
I made a new list for the 0.14 release so you can move them there.

Robert LaRubbio

unread,
Sep 24, 2012, 6:16:13 PM9/24/12
to motec...@googlegroups.com
There also are test failures in the asterisk IVR module.  It looks like some of it's unit tests depend on couch being installed.  We really need to get a build server set up with out any external dependencies so we can catch these errors when they are introduced.

I also kicked off the release hudson job but it has an error in an integration test:

-------------------------------------------------------------------------------
Test set: org.motechproject.scheduler.MotechSchedulerIT
-------------------------------------------------------------------------------
Tests run: 29, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 19.626 sec <<< FAILURE!
scheduleRunOnceJobTest(org.motechproject.scheduler.MotechSchedulerIT)  Time elapsed: 0.067 sec  <<< FAILURE!
junit.framework.AssertionFailedError: expected:<4> but was:<5>
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.failNotEquals(Assert.java:283)
	at junit.framework.Assert.assertEquals(Assert.java:64)
	at junit.framework.Assert.assertEquals(Assert.java:195)
	at junit.framework.Assert.assertEquals(Assert.java:201)
	at org.motechproject.scheduler.MotechSchedulerIT.scheduleRunOnceJobTest(MotechSchedulerIT.java:282)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
Is this something we can cleanup or should I just pull in the latest changes on master since that build is green?

-Rob
org.motechproject.server.asterisk.TestIVRService.txt

Robert LaRubbio

unread,
Sep 25, 2012, 2:30:49 PM9/25/12
to motec...@googlegroups.com
I'm looking over the failed integration test on the release buikld, and I've got two questions.  First, in MotechSchedulerIT is this code correct?

   public void setUp() {
        Calendar cal = Calendar.getInstance();
        cal.setTime(new Date());
        cal.add(1, Calendar.MINUTE);
        DateTime now = DateUtil.now();

        scheduledHour = now.getHourOfDay();
        scheduledMinute = now.getMinuteOfHour() + 1;
        scheduledSecond = now.getSecondOfMinute();
        if (scheduledMinute == 59) {                              <----- This line
            scheduledHour = (scheduledHour + 1) % 24;
            scheduledMinute = 0;
        }
    }

or should the == 59 be == 60?  

Second, if we have a comment like this '// TODO: may fail randomly' shouldn't we just disable the test until it is deterministic?

-Rob
Reply all
Reply to author
Forward
0 new messages