[AURON #2459] Resolve build info paths relative to auron-build.sh - #2461
Open
ShreyeshArangath wants to merge 1 commit into
Open
[AURON #2459] Resolve build info paths relative to auron-build.sh#2461ShreyeshArangath wants to merge 1 commit into
ShreyeshArangath wants to merge 1 commit into
Conversation
auron-build.sh resolved both the build info file and the Maven used to look up project.version relative to the caller's working directory. Run from anywhere other than the project root it wrote auron-build-info.properties outside the project, so the build never picked it up, and project.version was dropped from the file because the lookup failed into /dev/null and empty values are skipped. Resolve SCRIPT_DIR from BASH_SOURCE and use it for the build info file, reuse the already resolved MVN_CMD instead of a hardcoded ./build/mvn, and pass -f so Maven reads the project pom rather than falling back to its standalone pom, which reports version 1. Fail with the captured Maven output when the version cannot be resolved, rather than shipping a jar with no version in it.
ShreyeshArangath
marked this pull request as ready for review
August 10, 2026 17:03
slfan1989
self-requested a review
August 12, 2026 09:36
slfan1989
requested changes
Aug 12, 2026
| JAVA_VERSION=$(java -version 2>&1 | head -n 1 | awk '{print $3}' | tr -d '"') | ||
| PROJECT_VERSION=$(./build/mvn help:evaluate -N -Dexpression=project.version -Pspark-${SPARK_VER} -q -DforceStdout 2>/dev/null) | ||
| MVN_STDERR=$(mktemp) | ||
| if ! PROJECT_VERSION=$("$MVN_CMD" help:evaluate -N -f "$SCRIPT_DIR/pom.xml" -Dexpression=project.version -Pspark-${SPARK_VER} -q -DforceStdout 2>"$MVN_STDERR") \ |
Contributor
There was a problem hiding this comment.
Thanks for the contribution! The version lookup is now pinned to the project POM, but the final Maven invocation below still runs without -f "$SCRIPT_DIR/pom.xml". When the script is invoked outside the repository, build-info generation succeeds, but the actual build still fails with MissingProjectException because Maven searches for a POM in the caller's directory. Please also pin the final Maven invocation to the project POM and add regression coverage for running the complete local build from another directory.
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.
What changes were proposed in this pull request?
Fixes #2459.
auron-build.shresolved both the build info file and the Maven used to look upproject.versionrelative to the caller's working directory. Run from anywhere other than the project root, it wroteauron-build-info.propertiesoutside the project so the build never picked it up, and leftproject.versionout of the file entirely because the lookup failed into/dev/nulland empty values are skipped by the writing loop.Three changes:
SCRIPT_DIRfromBASH_SOURCEand use it forBUILD_INFO_FILE, so the file always lands in the project.MVN_CMDinstead of a hardcoded./build/mvn.-f "$SCRIPT_DIR/pom.xml"so Maven reads the project pom, and fail with the captured Maven output when the version cannot be resolved.The
-fpart is worth calling out. Without it,help:evaluaterun from another directory does not fail; Maven falls back to its synthetic standalone pom and reports version1, so the jar gets a plausible but wrong version. Pinning the pom and validating the result covers that.How was this patch tested?
Manually, on Spark 3.1 / Scala 2.12.
Before, from a directory outside the project,
project.versionis missing and the file is written to the wrong place:After, from the same directory:
Also checked: