OpenDaylight JIRA

OpenDaylight JIRA https://jira.opendaylight.org This file is an XML representation of an issue en-us

8.20.10

820010

22-06-2022

[YANGTOOLS-384] Migrate yangtools build to use releng https://jira.opendaylight.org/browse/YANGTOOLS-384 yangtools <p>Project has some special requirements for configuration of Jenkins build job, but still for maintance reasons it is better to be migrated to releng.</p> <p>Operating System: All<br/> Platform: All</p> YANGTOOLS-384

Migrate yangtools build to use releng

Improvement Resolved Done Unassigned Tony Tkacik Thu, 4 Dec 2014 09:16:16 +0000 Sun, 10 Apr 2022 18:35:26 +0000 Wed, 18 Mar 2015 13:07:13 +0000 0 4 <p>Can you be more specific to what the special requirements are?</p> <p>From what I can tell most jobs on the yangtools silo are disabled and only pretty standard jobs remain so the only special thing I see is that yangtool's verify job verifies against 3 different versions of Maven. Just want to be sure that's the only special case.</p> <p>I can help craft the JJB templates for this if necessary.</p> <p>Yes, we need Helium to verify with all three of them, master just needs 3.1.1 and 3.2.2. As a next step, for master, we want verify to also run with both Java 7 and 8 <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Took a crack at this and submitted 2 DRAFTs. The first one can be merged immediately and enables creates JJBs for Yangtools to build against Maven 3.0.x, 3.1.x, and 3.2.x for master and helium branches.</p> <p>You'll notice I did not create a Top level job to tie the 3 verify jobs together. This is because with Gerrit Trigger it's actually unnecessary, Gerrit Trigger will launch the 3 jobs simultaneously and actually fail the build if any one of them fails so achieves the same result (but gives a nice summary of all 3 job results).</p> <p>The 2nd patch adds the ability to also verify against multiple JDKs on top of Multiple Maven versions. This cannot be merged yet, we need to do stuff on the Releng side to ensure that the correct JDKs are downloaded during the build. I'm not sure what the right approach at the moment is since all the Auto download options provide Oracle JDKs. Perferrably we'd probably want to use Distro level versions of the JDKs to get OpenJDK which is what we're using to build today. I'll spend some more time investigating this aspect before making a recommendation.</p> <p>Multi Maven: <a href="https://git.opendaylight.org/gerrit/13669" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/13669</a><br/> Multi JDK: <a href="https://git.opendaylight.org/gerrit/13670" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/13670</a></p> <p>I've got a minor nit with the current patch for the Multi Maven submission <span class="error">[0]</span>, it's really, really minor and honestly can be ignored (see the commit for details). We do, however, need a yangtools committer to give a +1 before we'll merge it in.</p> <p>On the Multi JDK submission <span class="error">[1]</span> one of the images that I built for doing integration testing has all 3 of the current OpenJDK versions installed (1.6.0, 1.7.0, and 1.8.0) but only the JRE as the image is supposed to be for validation testing only (not a full build environment). I have several reasons for building a new "build" image up and adding all of the OpenJDK devel configurations is one of them.</p> <p>I'm a bit concerned though with adding multiple JDKs, not that Jenkins can't handle it, but that we'll need to update all the current jobs to make sure they specify which JDK to use as well, otherwise they may break. Thankfully, pretty much everything is on the autojob update configuration so it will be easy.</p> <p>We'll need to make sure that in the future any job that manually calls java (via a shell script for instance) does so using the auto-injected by Jenkins JAVA_HOME variable instead of just calling java blindly. Even with EL7 systems, the default system level java is openjdk-1.7.0 unless the alternatives are modified.</p> <p><span class="error">[0]</span> Multi Maven: <a href="https://git.opendaylight.org/gerrit/13669" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/13669</a><br/> <span class="error">[1]</span> Multi JDK: <a href="https://git.opendaylight.org/gerrit/13670" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/13670</a></p> <p>So the Multi JDK patch <a href="https://git.opendaylight.org/gerrit/13670" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/13670</a> is ready to go. However I think Yangtools isn't ready to build with Java 8. As stated in my Gerrit comment we get the following error when you try to build with Java 8.</p> <p><span class="error">[ERROR]</span> Failed to execute goal org.eclipse.xtend:xtend-maven-plugin:2.4.3:compile (default) on project binding-java-api-generator: Error compiling xtend sources in '/opt/jenkins/workspace/yangtools-verify-master-mvn31-jdk8/code-generator/binding-java-api-generator/src/main/java'. -> <span class="error">[Help 1]</span></p> <p>So if we merge the patch, Jenkins will -1 the in Gerrit since the Java 8 builder will fail. We should probably hold off on merging until we can confirm that it is possible to build Yangtools with Java 8.</p> <p>We are working on solving the xtend issue. We can park this issue until we get it ready again – ETA a week.</p> Blocks YANGTOOLS-391 Development External issue ID 2474 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i026w7: