https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/RELENG-103 releng <p>Before we have <a href="https://jira.opendaylight.org/browse/RELENG-102" title="New job like integration-multipatch-test which builds autorelease, without -Pq, without fixed order, with Maven options" class="issue-link" data-issue-key="RELENG-102">RELENG-102</a>, we want to just use the existing integration-multipatch-test-fluorine for what we are after in the parent JIRA: <a href="https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/</a> and <a href="http://docs.opendaylight.org/projects/releng-builder/en/latest/jenkins.html#jenkins-job-templates" class="external-link" target="_blank" rel="nofollow noopener">http://docs.opendaylight.org/projects/releng-builder/en/latest/jenkins.html#jenkins-job-templates</a>.</p> <p>What we are missing is be able to run builds on that job without -Pq so that we can catch not only compile time impacts, but also broken tests and other failures (such as the FindBugs failure which <a href="https://jira.opendaylight.org/browse/TSC-100" title="WriteTransaction.submit() to be annotated with @CheckReturnValue" class="issue-link" data-issue-key="TSC-100"><del>TSC-100</del></a> can cause).</p> <p>Luis volunteered to do something about this in today's integration call. Either just drop the -Pq or introduce a new keyword. This is better than a new parameter, because not veeryone has access to <a href="https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/build?delay=0sec" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/build?delay=0sec</a>.</p> RELENG-103

integration-multipatch-test-fluorine job should be able to run without -Pq

Sub-task RELENG-101 Medium Resolved Done Luis Gomez Michael Vorburger Thu, 26 Apr 2018 17:39:42 +0000 Mon, 7 May 2018 18:27:42 +0000 Wed, 2 May 2018 11:51:07 +0000 0 2 <p>This should work: <a href="https://git.opendaylight.org/gerrit/#/c/71492/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/71492/</a></p> <p>Thanks! I'll test this ASAP, for <a href="https://jira.opendaylight.org/browse/TSC-100" title="WriteTransaction.submit() to be annotated with @CheckReturnValue" class="issue-link" data-issue-key="TSC-100"><del>TSC-100</del></a> - trying to launch something now, but am on PTO tomorrow; more on Wed.</p> <p>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</p> <p>Next step could be either: </p> <ul class="alternate" type="square"> <li>Ask all Managed projects to produce a patch so that we can run the above with the additional patches and see where is fails.</li> <li>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.</li> </ul> <p>List of projects we need a patch (in dependency order):<br/> infrautils<br/> coe<br/> daexim<br/> openflowplugin<br/> ovsdb<br/> neutron<br/> lispflowmapping<br/> genius<br/> sfc<br/> netvirt</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=ecelgp" class="user-hover" rel="ecelgp">ecelgp</a> how about we track what you posted above in <a href="https://jira.opendaylight.org/browse/TSC-99" title="MDSAL Fluorine API breakage window 2" class="issue-link" data-issue-key="TSC-99"><del>TSC-99</del></a> 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 <a href="https://jira.opendaylight.org/browse/TSC-100" title="WriteTransaction.submit() to be annotated with @CheckReturnValue" class="issue-link" data-issue-key="TSC-100"><del>TSC-100</del></a>, using mdsal:61/66361/6,controller:60/66360/5, somewhat to my surprise, the <a href="https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/18/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/job/integration-multipatch-test-fluorine/18/</a> job PASSED... </p> <p>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 <a href="https://jira.opendaylight.org/browse/RELENG-103" title="integration-multipatch-test-fluorine job should be able to run without -Pq" class="issue-link" data-issue-key="RELENG-103"><del>RELENG-103</del></a> just yet... <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>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? <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/tongue.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>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.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=ecelgp" class="user-hover" rel="ecelgp">ecelgp</a> 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?</p> <p>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.</p> <p>I agree we can close this ticket, I already moved performed test to <a href="https://jira.opendaylight.org/browse/TSC-99" title="MDSAL Fluorine API breakage window 2" class="issue-link" data-issue-key="TSC-99"><del>TSC-99</del></a>.</p> <p>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 (<a href="https://jira.opendaylight.org/browse/RELENG-102" title="New job like integration-multipatch-test which builds autorelease, without -Pq, without fixed order, with Maven options" class="issue-link" data-issue-key="RELENG-102">RELENG-102</a>) 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.</p> <p>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.</p> <p>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.</p> <p>&gt; approach here is to enter the list of projects in AR and see which one breaks, i.e. needs a patch</p> <p>That's what <a href="https://github.com/vorburger/opendaylight-bot" class="external-link" target="_blank" rel="nofollow noopener">The Bot</a> 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 <a href="https://jira.opendaylight.org/browse/RELENG-106" title="The Bot (or the job?) must handle topics with several interrelated patches on the same project" class="issue-link" data-issue-key="RELENG-106"><del>RELENG-106</del></a>.</p> Blocks TSC-100 Relates RELENG-102 Development Rank 0|i03dz3: