On 17/01/2019 15:03, Lori Jakab via RT wrote: > On Thu, Jan 17, 2019 at 2:20 PM Anil Belur via RT > <[email protected]> wrote: >> On Thu Jan 17 01:13:50 2019, askb wrote: >>> On Wed Jan 16 13:31:24 2019, [email protected] wrote: >>>> Adding helpdesk. >>>> >>>> I suppose SET_JDK_VERSION should not be an array. >>>> >>>> -Lori >>> Greetings Lori: >>> >>> This approach for passing multiple java-versions (openjdk8 and >>> openjdk11) seem >>> to work for the maven-verify jobs but not for the javadocs-verify >>> jobs. This is because JJB ${job-name} expansion is handling the >>> ${java-version} when the job name has a variable name included. When >>> the job name does not have the ${java-version} this is passed as a >>> list to the job. >>> >>> I think we may need to make the scripts a little intelligence to >>> handle these scenarios or simply fix this in the job which requires to >>> be changed in global-jjb. I've have noted this in Jira and will work >>> on fixing this in global-jjb to make sure this works properly for >>> other jobs too. >>> >>> https://jira.linuxfoundation.org/browse/RELENG-1648 >>> >>> Thanks, >>> Anil >> Hello Lori: >> >> The below change in global-jjb should fix the issue with javadocs jobs. >> >> https://gerrit.linuxfoundation.org/infra/#/c/14233/ >> >> I've tested extending the jobs name with java-version on sandbox which works >> correctly. >> >> https://jenkins.opendaylight.org/sandbox/job/lispflowmapping-maven-javadoc-verify-neon-openjdk11 >> https://jenkins.opendaylight.org/sandbox/job/lispflowmapping-maven-javadoc-verify-neon-openjdk8 > Thanks for fixing the jobs! > > But I feel that this may be a waste of the already scarce infra > resources, for this Javadoc job the default JDK that the use for the > merge job should suffice. Especially if more projects will start > adding openjdk11 verify jobs, this may be significant added load.
Yes, and while we had parallel verify jobs during Java 7->8 migration, we should not have them now for exactly this reason. As noted in the Java 11 thread at discuss, having autorelease-openjdk11 is completely sufficient at this stage -- and it is only a two-hour job once a day. For the three MRI projects, which are not covered by autorelease, we can manually define maven-stage-openjdk11 jobs, so we have automated advice on potential regressions. Once the community arrives at a conclusion what we want to do, we can adjust accordingly. Keeping our resource consumption, though, is critical. Regards, Robert
binV9EqxJVtwR.bin
Description: application/rt-original-message
_______________________________________________ infrastructure mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/infrastructure
