Build and deploy through the wrapper on Jenkins - #12677
Merged
Merged
Conversation
Jenkins already provisions Maven with the wrapper for the build itself, but the deploy step still ran the `mvn` from the `maven_3_latest` Jenkins tool, so a release was published by a different Maven than the one that built it. `mavenBuild` runs first in the same workspace, so `./mvnw` is present by the time deploy runs. Also moves the wrapper provisioning to maven-wrapper-plugin 3.3.4 and Maven 3.9.12, matching what the GitHub Actions workflow already uses. This is the same pattern as apache/maven-jenkins-lib#22, which applies it to the shared library. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnodet
approved these changes
Aug 4, 2026
gnodet
left a comment
gnodet
left a comment
Contributor
There was a problem hiding this comment.
LGTM ✅ — Clean, low-risk change that aligns the Jenkins deploy step with the build step by using the Maven wrapper consistently.
Key observations:
- The build step already provisions the wrapper via
maven-wrapper-plugin, so./mvnwis guaranteed to be present when the deploy step runs. - The version bumps (wrapper-plugin 3.3.2→3.3.4, Maven 3.9.10→3.9.12) match what
origin/masterand the GHA workflow already use. - Previously the build used
./mvnw(Maven 3.9.x) but the deploy usedmvnfrom themaven_3_latestJenkins tool — potentially a different version. This PR fixes that inconsistency. - The added
-Vflag improves version traceability in deploy logs. - Note:
origin/masteralready has identical changes (commitsa9fda7d28fande25ec15e1b), so a companion PR for master is not needed.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of gnodet
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jenkins already provisions Maven with the wrapper for the build itself, but the deploy step still ran the
mvnfrom themaven_3_latestJenkins tool — so a release was published by a different Maven than the one that built it.mavenBuildruns first in the same workspace, so./mvnwis present by the time deploy runs.Also moves the wrapper provisioning to
maven-wrapper-plugin3.3.4 and Maven 3.9.12, matching what.github/workflows/maven.ymlalready uses. Both are on Central (verified).Same pattern as apache/maven-jenkins-lib#22, which applies it to the shared library. Part of #12676.
No
mastercompanion is needed:masteralready has both of these —./mvnw clean deploy -DdeployAtEnd=true -B -VatJenkinsfile:41andmaven-wrapper-plugin:3.3.4with-Dmaven=3.9.12at:70. This bringsmaven-4.0.xup to the same state.