build: parameterise the version with Maven CI-friendly versions - #128
Merged
Merged
Conversation
The version was hardcoded as 1.2.0-SNAPSHOT in six poms and three
Dockerfiles, in COPY paths and entrypoint scripts. A release meant editing
nine files, which is why the tag 1.1.0 and the source version had drifted
apart entirely.
Now one flag: mvn -Drevision=2.3.0, or --build-arg APP_VERSION=2.3.0. The
default in the parent pom keeps plain mvn install working unchanged, and
CI passes the derived release tag automatically.
Each image also copies its jar to a stable name, so the version never
reaches runtime. That is not cosmetic: the operator and service
entrypoints are written by a RUN heredoc with a quoted delimiter, so
${APP_VERSION} would be written literally and expand to empty at container
start, and the conversion-webhook ENTRYPOINT is JSON exec form where
Docker never expands variables at all.
Verified by building, not by reading: docker build with
APP_VERSION=9.9.9-test produces a jar reporting
Implementation-Version: 9.9.9-test, and a default build still succeeds.
That test found three bugs. flatten-maven-plugin was missing, so the
installed pom kept the literal ${revision} and the next module could not
resolve its parent - I had wrongly assumed it was unnecessary because
nothing is published to a Maven repo. mvn clean package never received
-Drevision. And ARG is per stage, so removing it from the runtime stage
broke the COPY --from=builder source path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019qeiQRFu8xAMRYWPdZewjG
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe build now uses a CI-overridable Maven revision. Dockerfiles pass ChangesVersioned build pipeline
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The PR centralizes Maven and Docker version handling while preserving the default build path; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (11 skipped: 11 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
The version was hardcoded as
1.2.0-SNAPSHOTin six poms and three Dockerfiles — in COPY paths and in entrypoint scripts. Releasing meant editing nine files by hand, which is why the tag1.1.0and the source version1.2.0-SNAPSHOThad drifted apart entirely.Now it is one flag:
CI passes it automatically via
stamp-app-version(EduIDE/.github#2), using the tag the shared workflow already derives — so a release taggedv2.3.0produces a jar reporting2.3.0.Verified by actually building
Not by reading the diff.
docker build --build-arg APP_VERSION=9.9.9-test:and a default build with no
--build-argstill succeeds.That build test found three bugs I would otherwise have shipped:
flatten-maven-pluginwas missing.mvn installwrites a pom that still contains the literal${revision}, so the next module cannot resolve its parent:The Dockerfiles build module-by-module with separate
mvninvocations, so every one hit this. I had assumed the plugin was unnecessary because nothing is published to a Maven repo; that was wrong.mvn clean packagenever received-Drevision. The jar would have been built at the default version while the COPY looked for the requested one.ARGis per stage. Removing it from the runtime stage broke theCOPY --from=buildersource path, which is build-time and resolves in the stage that declares it.The version no longer reaches runtime at all
Each image now copies its jar to a stable name (
operator.jar,service.jar,conversion-webhook.jar). That was not cosmetic:RUNheredoc with a quoted delimiter, so${APP_VERSION}would have been written literally into the script and expanded to empty at container startENTRYPOINTis JSON exec form, where Docker never expands variablesEither would have produced a container that builds fine and fails to start.
Also
stamp-app-version: trueon the build workflow, and.flattened-pom.xmladded to.gitignore.🤖 Generated with Claude Code
https://claude.ai/code/session_019qeiQRFu8xAMRYWPdZewjG
Summary by CodeRabbit
Enhancements
Chores