On Oct 6, 2018, at 2:10 PM, Michael Vorburger <vorburger@...> wrote:

On Sat, Oct 6, 2018 at 9:18 PM Michael Vorburger <vorburger@...> wrote:

On Sat, Oct 6, 2018 at 4:21 PM Michael Vorburger <vorburger@...> wrote:

Luis / multipatch job maintainers,

re. below, I am going to run multipatch and manually apply Robert's suggestion (thank you) to "change the build order to unblock others", but it occured to me that it would probably be useful to change this at source, if that's easy enough for you to do somewhere?

So, ideally, I think it would makes sense to change the BUILD_ORDER on https://jenkins.opendaylight.org/releng/view/integration/job/integration-multipatch-test-neon/build from its current default of:

odlparent yangtools infrautils mdsal controller serviceutils aaa netconf daexim bgpcep ovsdb neutron lispflowmapping openflowplugin coe genius sfc netvirt

to (note how "bgpcep" moves from somewhere arbitrary between daexim and ovsdb to after netvirt):

odlparent yangtools infrautils mdsal controller serviceutils aaa netconf daexim ovsdb neutron lispflowmapping openflowplugin coe genius sfc netvirt bgpcep 

actually, while we are at it, IMHO this would be even better to  see impacts on more projects faster:

odlparent yangtools infrautils mdsal controller serviceutils aaa netconf daexim ovsdb neutron openflowplugin coe genius sfc netvirt lispflowmapping  bgpcep

no this ^^^ would not be right, because (apparently) sfc needs lispflowmapping, so perhaps more like this it would be useful:

odlparent yangtools infrautils mdsal controller serviceutils aaa netconf daexim ovsdb neutron openflowplugin coe genius lispflowmapping sfc netvirt bgpcep

This would make it easier for anyone to use "multipatch-build:topic=..." and see impacts on more projects faster.

Tx,

M.

--

Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch

---------- Forwarded message ---------
From: Robert Varga <nite@...>
Date: Sat, Oct 6, 2018 at 3:39 PM
Subject: Re: bgpcep build failure in proposed topic:neon-mri ("Weather Item" TSC-132)
To: Michael Vorburger <vorburger@...>, Bgpcep-Dev <bgpcep-dev@...>
Cc: Kitt, Stephen <skitt@...>, <tsc@...> <tsc@...>

Bgpcep has no downstreams, changing the build order will unblock others...

Sent from my BlackBerry - the most secure mobile device - via the Orange Network

From: vorburger@... Sent: October 6, 2018 15:06 To: nite@...; bgpcep-dev@... Cc: skitt@...; tsc@... Subject: Re: bgpcep build failure in proposed topic:neon-mri ("Weather Item" TSC-132)

Dear maintainers of project bgpcep,

you are still failing topic:neon-mri, 

see https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/integration-multipatch-test-neon/53/console-timestamp.log.gz :

[ERROR]   ConfigLoaderImplTest.configLoaderImplTest:49 

11:35:53  processor.loadConfiguration(<any>);

11:35:53  Wanted 2 times:

11:35:53  -> at org.opendaylight.bgpcep.config.loader.impl.ConfigLoaderImplTest.configLoaderImplTest(ConfigLoaderImplTest.java:49)

11:35:53  But was 1 time:

11:35:53  -> at org.opendaylight.bgpcep.config.loader.impl.ConfigLoaderImpl.handleConfigFile(ConfigLoaderImpl.java:93)

11:35:53  

11:35:53  [INFO] 

11:35:53  [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0

also see previous https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/integration-multipatch-test-neon/52/console.log.gz :

[ERROR] Errors: 
[ERROR]   AddPathBasePathsTest.testUseCase1:142->AbstractAddPathTest.sendWithdrawalRouteAndCheckIsOnLocRib:190->AbstractAddPathTest.checkLocRib:207->AbstractAddPathTest.lambda$checkLocRib$0:210 » NullPointer
[INFO] 
[ERROR] Tests run: 71, Failures: 0, Errors: 1, Skipped: 1

This is now blocking wrapping up TSC-132 - will you adress this ASAP and let us know when we can rerun multipatch (without -Pq) ?

FTR: I'm also running a new "quick" multipatch just to see; and will record status for both quick and full builds in TSC-132 in the coming days.

Tx,

M.

--

Michael Vorburger, Red Hat
vorburger@... | IRC: vorburger @freenode | ~ = http://vorburger.ch

On Thu, Oct 4, 2018 at 4:51 PM Robert Varga <nite@...> wrote:

On 04/10/2018 16:48, Michael Vorburger wrote:
> Please raise a similar change for your project which fixes this problem.

MD-SAL regression, already fixed via a revert.

Regards,
Robert