This should work: https://git.opendaylight.org/gerrit/#/c/71492/

Thanks! I'll test this ASAP, for TSC-100 - trying to launch something now, but am on PTO tomorrow; more on Wed.

Michael, fyi this is the list of patches I tried (based on the topic binding-tlc-rpc): mdsal=55/69355/33:62/69362/30,controller=05/71205/6,aaa=19/71219/1,netconf=22/71222/2,bgpcep=27/71227/4

Next step could be either:

• Ask all Managed projects to produce a patch so that we can run the above with the additional patches and see where is fails.
• Ask the the next project in the dependency chain to produce a patch and run the above with the extra project. Once it passes move to the next project in the dependency chain.

List of projects we need a patch (in dependency order):
infrautils
coe
daexim
openflowplugin
ovsdb
neutron
lispflowmapping
genius
sfc
netvirt

ecelgp how about we track what you posted above in TSC-99 instead of here? That way we can already close this particular JIRA when the basic mechanism works. But I'm just not sure that it really does: The job I fired off an another topic for TSC-100, using mdsal:61/66361/6,controller:60/66360/5, somewhat to my surprise, the https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/18/ job PASSED...

But did that REALLY run an autorelease with FindBugs?? If so, then this means we can just merge the controller and mdsal changes, as the job should prove if any impact or not. I'm just sceptical if there really is no impact, because I don't entirely trust our new job from RELENG-103 just yet...

From what (little) I understand here, my integration-multipatch-test-fluorine/18/ JUST built mdsal and controller - NOT all of autorelease WITH those two patches - is that right? How can I get it to do what we want?

That is correct multi-patch job only builds whatever you tell in the patch list + distribution at the end. Building all projects is more like a new AR job we require.

ecelgp I'm trying "mdsal:61/66361/6,controller:60/66360/5,genius,netvirt" on (currently queued) integration-multipatch-test-fluorine/19/, hoping that means "please try mvn install with those 2 patches (making the breaking change), and then genius / netvirt master - to see if those still pass or need patches" - will that syntax work? Or if does not, would it be possible to make something like that work?

I can start looking at that job by the end of this week but maybe for the next immediate breakage we can just use the multi-patch job.

I agree we can close this ticket, I already moved performed test to TSC-99.

Hang on, but then this approach is not going work for the short term, like we had hoped, and we would have to have a new job (RELENG-102) rather sooner than later, right? What I really want is a job to SEE which projects FAIL and are affected. I don't want to have to "trust" projects to raise patches IFF they are affected. For a better Weather Item process (parent issue), we need to validate IFF projects are affected, and test their proposed patches.

multi-patch job just verifies individual patches entered manually, it does not detect if a downstream project breaks because an upstream patch or similar. That will require a new job in AR.

OK, it is been noted (I have never tested this way before) that if a project is mentioned in the multi-patch build without any patch, e.g. "mdsal:61/66361/6,controller:60/66360/5,genius,netvirt", then the job will use latest code in branch. So a new approach here is to enter the list of projects in AR and see which one breaks, i.e. needs a patch.

> approach here is to enter the list of projects in AR and see which one breaks, i.e. needs a patch

That's what The Bot now does. Let us close this sub task, as the goal originally set up for it here has been achieved. More about specific builds in the respective TSC ticket, and particular tooling issues in new sub-tasks, such as RELENG-106.