Check runtime Maven version is aligned with wrapper Maven version #36357
Conversation
| @@ -96,3 +96,20 @@ if (System.env.GITHUB_ACTIONS) { | |||
| } | |||
| } | |||
|
|
|||
| // Check current Maven version and Maven Wrapper version alignment | |||
| def runtimeInfo = (org.apache.maven.rtinfo.RuntimeInformation) session.lookup("org.apache.maven.rtinfo.RuntimeInformation") | |||
| def currentMavenVersion = runtimeInfo?.getMavenVersion() | |||
There was a problem hiding this comment.
Regarding variable naming: instead of current since current could be used to refer to the maven daemon version or the wrapper version, can we use runtimeMavenVersion?
| mavenWrapperPropertiesFile.withInputStream { | ||
| mavenWrapperProperties.load(it) | ||
| } | ||
| if(regexp = mavenWrapperProperties."distributionUrl" =~ /.*\/apache-maven-(.*)-bin\.zip/) { |
There was a problem hiding this comment.
This will work for Quarkus but we if the maven wrapper is distributed from a custom URL will this still work?
There was a problem hiding this comment.
I am parsing here a standard URL, this could not work with a custom URL indeed.
I am adding a comment to describe what is expected.
| if(regexp = mavenWrapperProperties."distributionUrl" =~ /.*\/apache-maven-(.*)-bin\.zip/) { | ||
| def wrapperMavenVersion = regexp.group(1) | ||
| if (currentMavenVersion && wrapperMavenVersion && wrapperMavenVersion != currentMavenVersion) { | ||
| log.warn("Maven Wrapper is configured with a different version (" + wrapperMavenVersion + ") than the current one (" + currentMavenVersion + "). This will negatively impact build caching.") |
There was a problem hiding this comment.
| log.warn("Maven Wrapper is configured with a different version (" + wrapperMavenVersion + ") than the current one (" + currentMavenVersion + "). This will negatively impact build caching.") | |
| log.warn("Maven Wrapper is configured with a different version (" + wrapperMavenVersion + ") than the runtime version (" + currentMavenVersion + "). This will negatively impact build consistency and build caching.") |
| def wrapperMavenVersion = regexp.group(1) | ||
| if (currentMavenVersion && wrapperMavenVersion && wrapperMavenVersion != currentMavenVersion) { | ||
| log.warn("Maven Wrapper is configured with a different version (" + wrapperMavenVersion + ") than the current one (" + currentMavenVersion + "). This will negatively impact build caching.") | ||
| buildScan.tag("misaligned-maven-version") |
There was a problem hiding this comment.
would it be valuable to add a custom value with the wrapper version? I'm assuming that the runtime version is already part of the scan
There was a problem hiding this comment.
I didn't think it was necessary at first thought as the version can be obtained in the Git repo, let's add it to simplify investigation if any 👍
There was a problem hiding this comment.
Good point. I'm not sure it is needed if it is in the repo then. It was just a thought.
There was a problem hiding this comment.
I'll add it, Guillaume will decide if they want it or not
| @@ -96,3 +96,23 @@ if (System.env.GITHUB_ACTIONS) { | |||
| } | |||
| } | |||
|
|
|||
| // Check current Maven version and Maven Wrapper version alignment | |||
There was a problem hiding this comment.
| // Check current Maven version and Maven Wrapper version alignment | |
| // Check runtime Maven version and Maven Wrapper version are aligned |
jprinet
changed the title
jprinet
force-pushed
the
feature/check-maven-version-alignment
branch
from
dec6905 to
38cb5e3
Compare
gsmet
force-pushed
the
feature/check-maven-version-alignment
branch
from
3e1587b to
12cb0c4
Compare
gsmet
force-pushed
the
feature/check-maven-version-alignment
branch
from
12cb0c4 to
325a1a8
Compare
gsmet
added
the
triage/waiting-for-ci
quarkus-bot
bot
removed
the
triage/waiting-for-ci
|
Thanks! |
Issue
When using the Maven daemon, the Maven version used can be different than the one specified by the Maven wrapper. The daemon is shipping a customized version of Maven, see here for details.
This can impact negatively the build cacheability as the Maven version is part of the cache key.
Goal of the PR
The only way to fix this issue is to have the Maven daemon using a configurable Maven version, which was pushed back in the linked ticket.
The proposal here is to tag the builds encountering this issue and add a console log to warn the user.
This will allow to identify the impacted builds.