Re: [opendaylight-dev] serviceutils view in jjb messing up my jenkins-job pushing

Thanh Ha <thanh.ha@...>

On Thu, Jun 21, 2018 at 11:27 AM Robert Varga <nite@...> wrote:
On 21/06/18 17:17, Thanh Ha wrote:
> On Thu, Jun 21, 2018 at 11:08 AM Robert Varga <nite@...
> <mailto:nite@...>> wrote:
>     On 21/06/18 16:50, Jamo Luhrsen wrote:
>     >> Seems like a breaking change for ODL's JJB users. We should document
>     >> this, update the example jenkins.ini.example in releng/builder and
>     >> notify the community when a change like this is requires users to
>     >> modify their environment.
>     >
>     > I think this is happening every 1-2 months lately.
>     Could this also explain why verify-javadoc jobs are suddenly using mvn35
>     instead of mvn33 ?
> Hi Robert,
> That was caused by this patch
> which was merged 9 weeks ago.
> Which was a result of this
> Jira when we were having
> off-by-1 artifact issues with the Nitrogen stream back when we were
> trying to get Nitrogen-SR3 out the door.
> There was a decision on the mailing
> list
> to migrate to Maven 3.5.3 moving forward so that we would (hopefully)
> stop hitting that off by 1 artifact bug in maven versions < 3.5.2.
> Initially we only rolled it out to merge jobs to get over the
> Nitrogen-SR3 blocker but eventually rolled it out to the remaining jobs.

Thanks for the clarification, but it was rolled out between

i.e. on June 19, with no mention of this happening. mdsal now cannot
successfully verify and after spending a day on the issue I am no closer
to seeing a way to resolve it.

I tracked this down. It was caused by the upgrade to global-jjb v0.21.0 patch:

After inspecting the commit log of global-jjb for versions between v0.19.2 to v0.21.0 and release notes:

The patch 10394 changes the "default" Maven version from mvn33 to mvn35 in the global-jjb template and in releng/builder we were not overriding the mvn-version for the javadoc job. Normally we override via the job-group here:

but the javadoc jobs are not in that list so was accepting the default value coming from upstream global-jjb. This is why the javadoc jobs did not switch to mvn35 when we migrated all the other jobs.

With that said, if mvn35 is causing issues for mdsal, we can explicitly set the version back to mvn33 for the javadoc job with this patch:

In hindsight this is definitely something we missed in evaluating impact of the global-jjb upgrade as missed the fact that javadoc job mvn-version setting was pulling in the default value rather than the value explicitly set by the ODL job group. This is because not all projects have javadocs to publish so it was not included in the job-group. Moving forward one solution is to ensure that every project that specifies a "javadoc" job in their JJB YAML that they explicitly set the mvn-version setting to ensure we do not get surprises like this again in the future.


Join { to automatically receive all group messages.