Skip to content

TEZ-4718: Modernize Jenkins and Yetus integration to ensure full build and UT run on every PR#498

Open
Aggarwal-Raghav wants to merge 7 commits into
apache:masterfrom
Aggarwal-Raghav:TEZ-4718
Open

TEZ-4718: Modernize Jenkins and Yetus integration to ensure full build and UT run on every PR#498
Aggarwal-Raghav wants to merge 7 commits into
apache:masterfrom
Aggarwal-Raghav:TEZ-4718

Conversation

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor

@Aggarwal-Raghav Aggarwal-Raghav commented May 15, 2026

  • Containerized Yetus Execution: Configured Apache Yetus to run entirely within an isolated Docker container using build-tools/docker/Dockerfile ensuring a reproducible build environment.
  • Removed Legacy Scripts: Deleted old custom shell scripts (build-tools/smart-apply-patch.sh and build-tools/test-patch.sh), delegating test orchestration entirely to upstream Apache Yetus.
  • Introduced Custom Yetus Personality: Created dev-support/tez-personality.sh to centralize and strictly control Tez-specific test execution logic, moving intelligence out of the Jenkinsfile.
  • Enforced Global Builds & Unit Tests: Configured the Yetus personality to unconditionally execute the compile and unit test phases on the root module for every PR. This guarantees that cross-module regressions are caught, even for infrastructure-only changes.
  • Smart Static Analysis: Optimized spotbugs, checkstyle, javac, and javadoc to run "smartly" (only on changed modules) to improve build times, while forcing full-project checks if critical files (like .proto or pom.xml) are modified.
  • Improved Artifact Archiving: Added post-build steps to automatically zip and archive all surefire-reports, keeping the Jenkins console clean while making granular test debugging much easier.

Flags REMOVED:

  • --skip-dirs=dev-support: Removed to allow Yetus to properly analyze and lint changes made to the CI infrastructure scripts themselves.
  • --shelldocs=.../dev-support/bin/shelldocs: Removed because the path doesn't exists; Use shellcheck bundled in the Docker image.
  • --proclimit=5500: Removed from CLI arguments. (Migrated to PROC_LIMIT inside tez-personality.sh).
  • --dockermemlimit=20g: Removed from CLI arguments. (Migrated to DOCKER_MEMORY inside tez-personality.sh).
  • --debug: Removed to reduce log spam in standard CI runs.

Flags ADDED:

  • --personality=.../tez-personality.sh: Added to load the newly created Tez-specific build and filtering logic.

@Aggarwal-Raghav Aggarwal-Raghav force-pushed the TEZ-4718 branch 4 times, most recently from c425d38 to e146d9c Compare May 15, 2026 16:11
@tez-yetus
Copy link
Copy Markdown

🎊 +1 overall

Vote Subsystem Runtime Logfile Comment
+0 🆗 reexec 1m 46s Docker mode activated.
_ Prechecks _
+1 💚 dupname 0m 0s No case conflicting files found.
+0 🆗 detsecrets 0m 0s detect-secrets was not available.
+0 🆗 shelldocs 0m 0s Shelldocs was not available.
+1 💚 @author 0m 0s The patch does not contain any @author tags.
_ master Compile Tests _
_ Patch Compile Tests _
+1 💚 codespell 0m 8s The patch generated 0 new + 0 unchanged - 2 fixed = 0 total (was 2)
+1 💚 blanks 0m 0s The patch has no blanks issues.
+1 💚 shellcheck 0m 1s The patch generated 0 new + 0 unchanged - 150 fixed = 0 total (was 150)
_ Other Tests _
+1 💚 asflicense 0m 34s The patch does not generate ASF License warnings.
3m 3s
Subsystem Report/Notes
Docker ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/5/artifact/out/Dockerfile
Optional Tests dupname asflicense codespell detsecrets shellcheck shelldocs
uname Linux 5c25ab76080c 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Build tool maven
Personality tez-personality.sh
git revision master / 383ffd9
Max. process+thread count 47 (vs. ulimit of 2000)
modules C: . U: .
Console output https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/5/console
versions git=2.43.0 maven=3.9.15 codespell=2.4.1 shellcheck=0.11.0
Powered by Apache Yetus 0.15.1 https://yetus.apache.org

This message was automatically generated.

@tez-yetus
Copy link
Copy Markdown

🎊 +1 overall

Vote Subsystem Runtime Logfile Comment
+0 🆗 reexec 1m 24s Docker mode activated.
_ Prechecks _
+1 💚 dupname 0m 0s No case conflicting files found.
+0 🆗 detsecrets 0m 0s detect-secrets was not available.
+0 🆗 shelldocs 0m 0s Shelldocs was not available.
+1 💚 @author 0m 0s The patch does not contain any @author tags.
_ master Compile Tests _
_ Patch Compile Tests _
+1 💚 codespell 0m 8s The patch generated 0 new + 0 unchanged - 2 fixed = 0 total (was 2)
+1 💚 blanks 0m 0s The patch has no blanks issues.
+1 💚 shellcheck 0m 1s The patch generated 0 new + 0 unchanged - 150 fixed = 0 total (was 150)
_ Other Tests _
+1 💚 asflicense 0m 34s The patch does not generate ASF License warnings.
2m 43s
Subsystem Report/Notes
Docker ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/6/artifact/out/Dockerfile
Optional Tests dupname asflicense codespell detsecrets shellcheck shelldocs
uname Linux 34092625aa00 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Build tool maven
Personality tez-personality.sh
git revision master / 383ffd9
Max. process+thread count 47 (vs. ulimit of 2000)
modules C: . U: .
Console output https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/6/console
versions git=2.43.0 maven=3.9.15 codespell=2.4.1 shellcheck=0.11.0
Powered by Apache Yetus 0.15.1 https://yetus.apache.org

This message was automatically generated.

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

Aggarwal-Raghav commented May 15, 2026

Phew! Now, it is running build and UT. The changes are inspired from apache phoenix project. Still few things needs to be iron out. Need to add -Ptools profile in the tez-personality.sh and thinking of excluding tez-ui from codespell

@tez-yetus
Copy link
Copy Markdown

💔 -1 overall

Vote Subsystem Runtime Logfile Comment
+0 🆗 reexec 1m 41s Docker mode activated.
_ Prechecks _
+1 💚 dupname 0m 0s No case conflicting files found.
+0 🆗 detsecrets 0m 0s detect-secrets was not available.
+0 🆗 shelldocs 0m 0s Shelldocs was not available.
+1 💚 @author 0m 0s The patch does not contain any @author tags.
-1 ❌ test4tests 0m 0s The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.
_ master Compile Tests _
+1 💚 mvninstall 9m 51s master passed
+1 💚 compile 5m 16s master passed
_ Patch Compile Tests _
+1 💚 mvninstall 7m 38s the patch passed
+1 💚 codespell 2m 37s The patch generated 0 new + 0 unchanged - 2 fixed = 0 total (was 2)
+1 💚 compile 5m 43s the patch passed
+1 💚 blanks 0m 0s The patch has no blanks issues.
+1 💚 shellcheck 0m 2s The patch generated 0 new + 0 unchanged - 150 fixed = 0 total (was 150)
_ Other Tests _
-1 ❌ unit 95m 16s /patch-unit-root.txt root in the patch passed.
+1 💚 asflicense 1m 15s The patch does not generate ASF License warnings.
131m 18s
Reason Tests
Failed junit tests tez.dag.app.rm.TestTaskScheduler
tez.test.TestTezJobs
tez.test.TestAMRecoveryAggregationBroadcast
tez.runtime.library.conf.TestOrderedPartitionedKVEdgeConfig
tez.dag.library.vertexmanager.TestShuffleVertexManager
tez.runtime.library.conf.TestUnorderedPartitionedKVEdgeConfig
Subsystem Report/Notes
Docker ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/7/artifact/out/Dockerfile
Optional Tests dupname compile unit asflicense codespell detsecrets shellcheck shelldocs
uname Linux 588021b46ebb 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Build tool maven
Personality tez-personality.sh
git revision master / 383ffd9
Test Results https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/7/testReport/
Max. process+thread count 1370 (vs. ulimit of 5500)
modules C: . U: .
Console output https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/7/console
versions git=2.43.0 maven=3.9.15 codespell=2.4.1 shellcheck=0.11.0
Powered by Apache Yetus 0.15.1 https://yetus.apache.org

This message was automatically generated.

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

@abstractdog , the UT ran without the *.java extension changes. I would appreciate a feedback on this behaviour.

@tez-yetus
Copy link
Copy Markdown

💔 -1 overall

Vote Subsystem Runtime Logfile Comment
+0 🆗 reexec 0m 37s Docker mode activated.
_ Prechecks _
+1 💚 dupname 0m 0s No case conflicting files found.
+0 🆗 detsecrets 0m 0s detect-secrets was not available.
+0 🆗 shelldocs 0m 0s Shelldocs was not available.
+1 💚 @author 0m 0s The patch does not contain any @author tags.
-1 ❌ test4tests 0m 0s The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.
_ master Compile Tests _
+1 💚 mvninstall 6m 55s master passed
+1 💚 compile 3m 55s master passed
_ Patch Compile Tests _
+1 💚 mvninstall 5m 55s the patch passed
+1 💚 codespell 1m 47s The patch generated 0 new + 0 unchanged - 2 fixed = 0 total (was 2)
+1 💚 compile 3m 54s the patch passed
+1 💚 blanks 0m 0s The patch has no blanks issues.
+1 💚 shellcheck 0m 1s The patch generated 0 new + 0 unchanged - 150 fixed = 0 total (was 150)
_ Other Tests _
+1 💚 unit 68m 47s root in the patch passed.
+1 💚 asflicense 0m 57s The patch does not generate ASF License warnings.
94m 16s
Subsystem Report/Notes
Docker ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/8/artifact/out/Dockerfile
Optional Tests dupname compile unit asflicense codespell detsecrets shellcheck shelldocs
uname Linux c611ee8d3db9 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Build tool maven
Personality tez-personality.sh
git revision master / 383ffd9
Test Results https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/8/testReport/
Max. process+thread count 1304 (vs. ulimit of 5500)
modules C: . U: .
Console output https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/8/console
versions git=2.43.0 maven=3.9.15 codespell=2.4.1 shellcheck=0.11.0
Powered by Apache Yetus 0.15.1 https://yetus.apache.org

This message was automatically generated.

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

So, between Run7 and Run8 the the build time has reduced from:

  • Run 7 Total Time: 131m 18s
  • Run 8 Total Time: 94m 16s
    27 minutes were saved from the CI time because of dropping the -Ptest-patch during the unit test phase (which dropped the unit test duration from 95m to 68m)

Point to Ponder:
Yetus is running build 4 times:

  1. maven install: master: mvn clean install on master branch.
  2. master compilation: pre-patch: mvn clean test-compile -Ptest-patch on master branch, Uses test-patch profile to count the warnings.
  3. maven install: patch: mvn clean install runs on PR/patch (Master + PR changes)
  4. master compilation: patch: mvn clean test-compile -Ptest-patch runs on PR/patch (Master + PR changes) to check for the warnings.

Here is breakdown of each mvn clean command:

  1. maven install: master (Build 1) : Elapsed: 6m 55s
  2. master compilation: pre-patch (Build 2): Elapsed: 3m 55s
  3. maven install: patch (Build 3): Elapsed: 5m 55s
  4. master compilation: patch (Build 4): Elapsed: 3m 54s

Question,
Ques1 -> do we need compile plugin which is being used for warning diff calculation? but it is taking approx 8 min i.e. 2 and 4.
Ques2 -> We can remove Step 1 and 3 as well by doing YETUS_ARGS+=("--plugins=all,-mvninstall") , this is just putting the jars in .m2

I think keeping the compile stage makes more sense as it takes less time and check the project for sytax error. Also, unit: patch will anyway build and test the whole project.

@abstractdog
Copy link
Copy Markdown
Contributor

  • Containerized Yetus Execution: Configured Apache Yetus to run entirely within an isolated Docker container using build-tools/docker/Dockerfile ensuring a reproducible build environment.
  • Removed Legacy Scripts: Deleted old custom shell scripts (build-tools/smart-apply-patch.sh and build-tools/test-patch.sh), delegating test orchestration entirely to upstream Apache Yetus.
  • Introduced Custom Yetus Personality: Created dev-support/tez-personality.sh to centralize and strictly control Tez-specific test execution logic, moving intelligence out of the Jenkinsfile.
  • Enforced Global Builds & Unit Tests: Configured the Yetus personality to unconditionally execute the compile and unit test phases on the root module for every PR. This guarantees that cross-module regressions are caught, even for infrastructure-only changes.
  • Smart Static Analysis: Optimized spotbugs, checkstyle, javac, and javadoc to run "smartly" (only on changed modules) to improve build times, while forcing full-project checks if critical files (like .proto or pom.xml) are modified.
  • Improved Artifact Archiving: Added post-build steps to automatically zip and archive all surefire-reports, keeping the Jenkins console clean while making granular test debugging much easier.

Flags REMOVED:

  • --skip-dirs=dev-support: Removed to allow Yetus to properly analyze and lint changes made to the CI infrastructure scripts themselves.
  • --shelldocs=.../dev-support/bin/shelldocs: Removed because the path doesn't exists; Use shellcheck bundled in the Docker image.
  • --proclimit=5500: Removed from CLI arguments. (Migrated to PROC_LIMIT inside tez-personality.sh).
  • --dockermemlimit=20g: Removed from CLI arguments. (Migrated to DOCKER_MEMORY inside tez-personality.sh).
  • --debug: Removed to reduce log spam in standard CI runs.

Flags ADDED:

  • --personality=.../tez-personality.sh: Added to load the newly created Tez-specific build and filtering logic.

just for clarity's sake, this is not a new thing, right?

Containerized Yetus Execution: Configured Apache Yetus to run entirely within an isolated Docker container using build-tools/docker/Dockerfile ensuring a reproducible build environment.

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

  • Containerized Yetus Execution: Configured Apache Yetus to run entirely within an isolated Docker container using build-tools/docker/Dockerfile ensuring a reproducible build environment.
  • Removed Legacy Scripts: Deleted old custom shell scripts (build-tools/smart-apply-patch.sh and build-tools/test-patch.sh), delegating test orchestration entirely to upstream Apache Yetus.
  • Introduced Custom Yetus Personality: Created dev-support/tez-personality.sh to centralize and strictly control Tez-specific test execution logic, moving intelligence out of the Jenkinsfile.
  • Enforced Global Builds & Unit Tests: Configured the Yetus personality to unconditionally execute the compile and unit test phases on the root module for every PR. This guarantees that cross-module regressions are caught, even for infrastructure-only changes.
  • Smart Static Analysis: Optimized spotbugs, checkstyle, javac, and javadoc to run "smartly" (only on changed modules) to improve build times, while forcing full-project checks if critical files (like .proto or pom.xml) are modified.
  • Improved Artifact Archiving: Added post-build steps to automatically zip and archive all surefire-reports, keeping the Jenkins console clean while making granular test debugging much easier.

Flags REMOVED:

  • --skip-dirs=dev-support: Removed to allow Yetus to properly analyze and lint changes made to the CI infrastructure scripts themselves.
  • --shelldocs=.../dev-support/bin/shelldocs: Removed because the path doesn't exists; Use shellcheck bundled in the Docker image.
  • --proclimit=5500: Removed from CLI arguments. (Migrated to PROC_LIMIT inside tez-personality.sh).
  • --dockermemlimit=20g: Removed from CLI arguments. (Migrated to DOCKER_MEMORY inside tez-personality.sh).
  • --debug: Removed to reduce log spam in standard CI runs.

Flags ADDED:

  • --personality=.../tez-personality.sh: Added to load the newly created Tez-specific build and filtering logic.

just for clarity's sake, this is not a new thing, right?

Containerized Yetus Execution: Configured Apache Yetus to run entirely within an isolated Docker container using build-tools/docker/Dockerfile ensuring a reproducible build environment.

yeah yeah. --docker flag was present earlier as well

@abstractdog
Copy link
Copy Markdown
Contributor

So, between Run7 and Run8 the the build time has reduced from:

  • Run 7 Total Time: 131m 18s
  • Run 8 Total Time: 94m 16s
    27 minutes were saved from the CI time because of dropping the -Ptest-patch during the unit test phase (which dropped the unit test duration from 95m to 68m)

Point to Ponder: Yetus is running build 4 times:

  1. maven install: master: mvn clean install on master branch.
  2. master compilation: pre-patch: mvn clean test-compile -Ptest-patch on master branch, Uses test-patch profile to count the warnings.
  3. maven install: patch: mvn clean install runs on PR/patch (Master + PR changes)
  4. master compilation: patch: mvn clean test-compile -Ptest-patch runs on PR/patch (Master + PR changes) to check for the warnings.

Here is breakdown of each mvn clean command:

  1. maven install: master (Build 1) : Elapsed: 6m 55s
  2. master compilation: pre-patch (Build 2): Elapsed: 3m 55s
  3. maven install: patch (Build 3): Elapsed: 5m 55s
  4. master compilation: patch (Build 4): Elapsed: 3m 54s

Question, Ques1 -> do we need compile plugin which is being used for warning diff calculation? but it is taking approx 8 min i.e. 2 and 4. Ques2 -> We can remove Step 1 and 3 as well by doing YETUS_ARGS+=("--plugins=all,-mvninstall") , this is just putting the jars in .m2

I think keeping the compile stage makes more sense as it takes less time and check the project for sytax error. Also, unit: patch will anyway build and test the whole project.

@Aggarwal-Raghav : left some syntax comments, also thought about your questions here:

what about shooting for all with an "install" command, so having 2 stages (master + patch):

mvn clean install -Ptest-patch

and taking one more look, what value does the test-patch profile bring at all?

tez/pom.xml

Lines 1236 to 1256 in 383ffd9

<profile>
<id>test-patch</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<fork>true</fork>
<compilerArguments>
<Xlint/>
<Xmaxwarns>9999</Xmaxwarns>
</compilerArguments>
</configuration>
</plugin>
</plugins>
</build>
</profile>

is it just for having custom compiler arguments, other than what we have in case of a simple mvn clean install command?

also, I guess the test-patch naming was brought by TEZ-1313 in the early years of the project (the name must have matched the yetus terminology): I'm just thinking aloud, considering that test-patch.sh is removed from the codebase now, we can also rename/refactor profiles if they make more sense (not necessary, just an idea)

Comment thread dev-support/tez-personality.sh Outdated
## @stability evolving
## @replaceable no
function personality_globals
{
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got used to not having a line break before {, looks strange, would you consider doing function personality_globals {? if you agree, please take care of the other methods too

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK. will handle it

Comment thread dev-support/tez-personality.sh Outdated
Comment on lines +27 to +46
# shellcheck disable=SC2034
PROJECT_NAME=tez
# shellcheck disable=SC2034
BUILDTOOL=maven
# shellcheck disable=SC2034
PATCH_BRANCH_DEFAULT=master
# shellcheck disable=SC2034
JIRA_ISSUE_RE='^TEZ-[0-9]+$'
# shellcheck disable=SC2034
GITHUB_REPO="apache/tez"

# Increase memory for maven
# shellcheck disable=SC2034
MAVEN_OPTS="${MAVEN_OPTS:-"-Xmx4g -XX:+UseG1GC"}"

# Default Yetus settings
# shellcheck disable=SC2034
DOCKER_MEMORY="20g"
# shellcheck disable=SC2034
PROC_LIMIT=5500
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not simply exporting these and getting rid of SC2034?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will do.

{
local filename=$1

yetus_debug "Tez file filter: ${filename}"
Copy link
Copy Markdown
Contributor

@abstractdog abstractdog May 17, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked runs no.7 and no.8 and haven't seen "Tez file filter", am I supposed to see it?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--debug flag is removed from Jenkinsfile as it was too much verbose. Once --debug is enabled then this Tez file filter: will be printed

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, I'm fine with that, so in case of an evil pre-commit issue, --debug can be added to the jenkins pipeline script while manually Replaying the job

Screenshot 2026-05-18 at 11 30 56

I'm usually against comments containing code, but in this case, a commented-out --debug option could be really helpful, what do you think?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable. Will address it by EOD.

Comment thread dev-support/tez-personality.sh Outdated
Comment thread dev-support/tez-personality.sh Outdated
@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

Most of the tez-personality.sh was inspired from https://github.com/apache/phoenix/blob/master/dev/phoenix-personality.sh will address your comments.

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

@abstractdog , regarding your above question on test-patch profile.

Let me share my understanding:

  1. By default, the standard maven-compiler-plugin hides many lint warnings and Yetus relies on doing a diff of the warnings on master vs the warnings on the PR and tells that, PR has introduced 2 more warning or fixed 2 warning for instance. Frankly, I don't see much value of that because in future if JDK25 deprecates a API then this warning diff will flag it. For Tez-1.0.0 community can take a call whether to keep track of warning or remove this profile from codebase. Below table should help in making decision
  2. From my short experience with yetus, it compare things with the baseline master branch against your PR. I couldn't find a way to just run mvninstall yetus plugin or compile yetus plugin only on PR/patch and ignore master.

Let me clarify a thing:

  1. eliminating YETUS completley, is it acceptable? and move everything to standard Jenkinsfile? We'll lose the yetus summary output and spotbugs/checkstyle/linter which comes out of the box in yetus. Then it will be just like hive project.
Feature Option 1 (Maximum Strictness) Option 2 (The Sweet Spot) Option 3 (Maximum Speed)
Yetus Phases Enabled mvninstall, compile, unit compile, unit
(Disabled: mvninstall)
unit only
(Disabled: mvninstall, compile)
Step 1: Baseline maven install: master
master compilation: pre-patch
master compilation: pre-patch (Skipped entirely)
Step 2: Patch Build maven install: patch
master compilation: patch
master compilation: patch (Skipped entirely)
Step 3: Test Execution unit: patch unit: patch unit: patch
Estimated Maven Overhead ~20 minutes ~8 minutes 0 minutes
Pros Maximum safety. Fails early on missing dependencies. Drops JAR packaging time. Retains test-patch profile and early syntax failure detection and tracks compiler warning diffs. Absolute fastest pipeline.
Cons Very slow. Creates redundant JARs that unit doesn't strictly need. Very slight overhead to count warnings. Loses all warning tracking (e.g., deprecations). Syntax errors fail deep in the unit phase instead of failing early.

@tez-yetus
Copy link
Copy Markdown

💔 -1 overall

Vote Subsystem Runtime Logfile Comment
+0 🆗 reexec 0m 31s Docker mode activated.
_ Prechecks _
+1 💚 dupname 0m 0s No case conflicting files found.
+0 🆗 detsecrets 0m 0s detect-secrets was not available.
+0 🆗 shelldocs 0m 0s Shelldocs was not available.
+1 💚 @author 0m 0s The patch does not contain any @author tags.
-1 ❌ test4tests 0m 0s The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.
_ master Compile Tests _
+1 💚 mvninstall 6m 59s master passed
+1 💚 compile 3m 54s master passed
_ Patch Compile Tests _
+1 💚 mvninstall 5m 54s the patch passed
+1 💚 codespell 1m 47s The patch generated 0 new + 0 unchanged - 2 fixed = 0 total (was 2)
+1 💚 compile 3m 55s the patch passed
+1 💚 blanks 0m 0s The patch has no blanks issues.
+1 💚 shellcheck 0m 1s The patch generated 0 new + 0 unchanged - 150 fixed = 0 total (was 150)
_ Other Tests _
+1 💚 unit 71m 0s root in the patch passed.
+1 💚 asflicense 1m 4s The patch does not generate ASF License warnings.
96m 33s
Subsystem Report/Notes
Docker ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/9/artifact/out/Dockerfile
Optional Tests dupname compile unit asflicense codespell detsecrets shellcheck shelldocs
uname Linux 8a90d7d97d80 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Build tool maven
Personality tez-personality.sh
git revision master / 383ffd9
Test Results https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/9/testReport/
Max. process+thread count 1418 (vs. ulimit of 5500)
modules C: . U: .
Console output https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/9/console
versions git=2.43.0 maven=3.9.15 codespell=2.4.1 shellcheck=0.11.0
Powered by Apache Yetus 0.15.1 https://yetus.apache.org

This message was automatically generated.

@abstractdog
Copy link
Copy Markdown
Contributor

abstractdog commented May 18, 2026

@abstractdog , regarding your above question on test-patch profile.

Let me share my understanding:

  1. By default, the standard maven-compiler-plugin hides many lint warnings and Yetus relies on doing a diff of the warnings on master vs the warnings on the PR and tells that, PR has introduced 2 more warning or fixed 2 warning for instance. Frankly, I don't see much value of that because in future if JDK25 deprecates a API then this warning diff will flag it. For Tez-1.0.0 community can take a call whether to keep track of warning or remove this profile from codebase. Below table should help in making decision
  2. From my short experience with yetus, it compare things with the baseline master branch against your PR. I couldn't find a way to just run mvninstall yetus plugin or compile yetus plugin only on PR/patch and ignore master.

Let me clarify a thing:

  1. eliminating YETUS completley, is it acceptable? and move everything to standard Jenkinsfile? We'll lose the yetus summary output and spotbugs/checkstyle/linter which comes out of the box in yetus. Then it will be just like hive project.

Feature Option 1 (Maximum Strictness) Option 2 (The Sweet Spot) Option 3 (Maximum Speed)
Yetus Phases Enabled mvninstall, compile, unit compile, unit
(Disabled: mvninstall) unit only
(Disabled: mvninstall, compile)
Step 1: Baseline maven install: master
master compilation: pre-patch master compilation: pre-patch (Skipped entirely)
Step 2: Patch Build maven install: patch
master compilation: patch master compilation: patch (Skipped entirely)
Step 3: Test Execution unit: patch unit: patch unit: patch
Estimated Maven Overhead ~20 minutes ~8 minutes 0 minutes
Pros Maximum safety. Fails early on missing dependencies. Drops JAR packaging time. Retains test-patch profile and early syntax failure detection and tracks compiler warning diffs. Absolute fastest pipeline.
Cons Very slow. Creates redundant JARs that unit doesn't strictly need. Very slight overhead to count warnings. Loses all warning tracking (e.g., deprecations). Syntax errors fail deep in the unit phase instead of failing early.


UPDATE: this comment might be outdated, check the next one first: #498 (comment)


I would go for "Option 1 (Maximum Strictness)", even if I like the optimization in the "Option 2 (The Sweet Spot)":

  1. there could be many maven stages between compile and install, which we should cover (e.g. not sure, but maybe javadoc, etc.): using compile only could end up silently breaking things (and we're going to face them before a release)
  2. by running all the unit tests - as that's what we're trying to achieve now - we vote for full coverage, so we tend to accept longer runtimes for maximum strictness: if it's too bad, we can optimize later, but for now, we can afford this -> given the pace of Tez project, a few longer runs are absolutely okay, so from this point of view, I personally don't care about "Creates redundant JARs that unit doesn't strictly need."

regarding discontinuing Yetus: this points too far and needs community consensus: I mean that's okay, but the PR hits the local optima, I'm really satisfied with short-/mid-term

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

@abstractdog , I'll create 2 dummy PR to test this jenkins change on TEZ-4708 and TEZ-4711.
Both PR will give more confidence in the latest jenkins change and maybe find some early issues if they surface.

@abstractdog
Copy link
Copy Markdown
Contributor

@abstractdog , regarding your above question on test-patch profile.
Let me share my understanding:

  1. By default, the standard maven-compiler-plugin hides many lint warnings and Yetus relies on doing a diff of the warnings on master vs the warnings on the PR and tells that, PR has introduced 2 more warning or fixed 2 warning for instance. Frankly, I don't see much value of that because in future if JDK25 deprecates a API then this warning diff will flag it. For Tez-1.0.0 community can take a call whether to keep track of warning or remove this profile from codebase. Below table should help in making decision
  2. From my short experience with yetus, it compare things with the baseline master branch against your PR. I couldn't find a way to just run mvninstall yetus plugin or compile yetus plugin only on PR/patch and ignore master.

Let me clarify a thing:

  1. eliminating YETUS completley, is it acceptable? and move everything to standard Jenkinsfile? We'll lose the yetus summary output and spotbugs/checkstyle/linter which comes out of the box in yetus. Then it will be just like hive project.

Feature Option 1 (Maximum Strictness) Option 2 (The Sweet Spot) Option 3 (Maximum Speed)
Yetus Phases Enabled mvninstall, compile, unit compile, unit
(Disabled: mvninstall) unit only
(Disabled: mvninstall, compile)
Step 1: Baseline maven install: master
master compilation: pre-patch master compilation: pre-patch (Skipped entirely)
Step 2: Patch Build maven install: patch
master compilation: patch master compilation: patch (Skipped entirely)
Step 3: Test Execution unit: patch unit: patch unit: patch
Estimated Maven Overhead ~20 minutes ~8 minutes 0 minutes
Pros Maximum safety. Fails early on missing dependencies. Drops JAR packaging time. Retains test-patch profile and early syntax failure detection and tracks compiler warning diffs. Absolute fastest pipeline.
Cons Very slow. Creates redundant JARs that unit doesn't strictly need. Very slight overhead to count warnings. Loses all warning tracking (e.g., deprecations). Syntax errors fail deep in the unit phase instead of failing early.

I would go for "Option 1 (Maximum Strictness)", even if I like the optimization in the "Option 2 (The Sweet Spot)":

  1. there could be many maven stages between compile and install, which we should cover (e.g. not sure, but maybe javadoc, etc.): using compile only could end up silently breaking things (and we're going to face them before a release)
  2. by running all the unit tests - as that's what we're trying to achieve now - we vote for full coverage, so we tend to accept longer runtimes for maximum strictness: if it's too bad, we can optimize later, but for now, we can afford this -> given the pace of Tez project, a few longer runs are absolutely okay, so from this point of view, I personally don't care about "Creates redundant JARs that unit doesn't strictly need."

regarding discontinuing Yetus: this points too far and needs community consensus: I mean that's okay, but the PR hits the local optima, I'm really satisfied with short-/mid-term

hm, wait, I just realized again that github actions cover the mvn clean install scenario by running:

mvn --batch-mode --no-transfer-progress clean install
-DskipTests -Dmaven.javadoc.skip=true

mvn --batch-mode --no-transfer-progress clean install -DskipTests -Dmaven.javadoc.skip=true

which is even better, as it runs on multiple platforms

considering the minimal time difference between these options (on my laptop):

mvn --batch-mode --no-transfer-progress clean install -DskipTests -Dmaven.javadoc.skip=true
...
[INFO] Total time:  50.257 s
mvn --batch-mode --no-transfer-progress clean install -DskipTests
...
[INFO] Total time:  49.779 s

so what about running full mvn install in github actions, and going for "Option 2 (The Sweet Spot)" in yetus?

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

Aggarwal-Raghav commented May 18, 2026

@abstractdog , regarding your above question on test-patch profile.
Let me share my understanding:

  1. By default, the standard maven-compiler-plugin hides many lint warnings and Yetus relies on doing a diff of the warnings on master vs the warnings on the PR and tells that, PR has introduced 2 more warning or fixed 2 warning for instance. Frankly, I don't see much value of that because in future if JDK25 deprecates a API then this warning diff will flag it. For Tez-1.0.0 community can take a call whether to keep track of warning or remove this profile from codebase. Below table should help in making decision
  2. From my short experience with yetus, it compare things with the baseline master branch against your PR. I couldn't find a way to just run mvninstall yetus plugin or compile yetus plugin only on PR/patch and ignore master.

Let me clarify a thing:

  1. eliminating YETUS completley, is it acceptable? and move everything to standard Jenkinsfile? We'll lose the yetus summary output and spotbugs/checkstyle/linter which comes out of the box in yetus. Then it will be just like hive project.

Feature Option 1 (Maximum Strictness) Option 2 (The Sweet Spot) Option 3 (Maximum Speed)
Yetus Phases Enabled mvninstall, compile, unit compile, unit
(Disabled: mvninstall) unit only
(Disabled: mvninstall, compile)
Step 1: Baseline maven install: master
master compilation: pre-patch master compilation: pre-patch (Skipped entirely)
Step 2: Patch Build maven install: patch
master compilation: patch master compilation: patch (Skipped entirely)
Step 3: Test Execution unit: patch unit: patch unit: patch
Estimated Maven Overhead ~20 minutes ~8 minutes 0 minutes
Pros Maximum safety. Fails early on missing dependencies. Drops JAR packaging time. Retains test-patch profile and early syntax failure detection and tracks compiler warning diffs. Absolute fastest pipeline.
Cons Very slow. Creates redundant JARs that unit doesn't strictly need. Very slight overhead to count warnings. Loses all warning tracking (e.g., deprecations). Syntax errors fail deep in the unit phase instead of failing early.

I would go for "Option 1 (Maximum Strictness)", even if I like the optimization in the "Option 2 (The Sweet Spot)":

  1. there could be many maven stages between compile and install, which we should cover (e.g. not sure, but maybe javadoc, etc.): using compile only could end up silently breaking things (and we're going to face them before a release)
  2. by running all the unit tests - as that's what we're trying to achieve now - we vote for full coverage, so we tend to accept longer runtimes for maximum strictness: if it's too bad, we can optimize later, but for now, we can afford this -> given the pace of Tez project, a few longer runs are absolutely okay, so from this point of view, I personally don't care about "Creates redundant JARs that unit doesn't strictly need."

regarding discontinuing Yetus: this points too far and needs community consensus: I mean that's okay, but the PR hits the local optima, I'm really satisfied with short-/mid-term

hm, wait, I just realized again that github actions cover the mvn clean install scenario by running:

mvn --batch-mode --no-transfer-progress clean install
-DskipTests -Dmaven.javadoc.skip=true

mvn --batch-mode --no-transfer-progress clean install -DskipTests -Dmaven.javadoc.skip=true

which is even better, as it runs on multiple platforms

considering the minimal time difference between these options (on my laptop):

mvn --batch-mode --no-transfer-progress clean install -DskipTests -Dmaven.javadoc.skip=true
...
[INFO] Total time:  50.257 s
mvn --batch-mode --no-transfer-progress clean install -DskipTests
...
[INFO] Total time:  49.779 s

so what about running full mvn install in github actions, and going for "Option 2 (The Sweet Spot)" in yetus?

To clarify, you'll need to configure GitHub Actions to run automatically on pull requests. I assume you're currently initiating them manually for each pull request..

@abstractdog
Copy link
Copy Markdown
Contributor

@abstractdog , regarding your above question on test-patch profile.
Let me share my understanding:

  1. By default, the standard maven-compiler-plugin hides many lint warnings and Yetus relies on doing a diff of the warnings on master vs the warnings on the PR and tells that, PR has introduced 2 more warning or fixed 2 warning for instance. Frankly, I don't see much value of that because in future if JDK25 deprecates a API then this warning diff will flag it. For Tez-1.0.0 community can take a call whether to keep track of warning or remove this profile from codebase. Below table should help in making decision
  2. From my short experience with yetus, it compare things with the baseline master branch against your PR. I couldn't find a way to just run mvninstall yetus plugin or compile yetus plugin only on PR/patch and ignore master.

Let me clarify a thing:

  1. eliminating YETUS completley, is it acceptable? and move everything to standard Jenkinsfile? We'll lose the yetus summary output and spotbugs/checkstyle/linter which comes out of the box in yetus. Then it will be just like hive project.

Feature Option 1 (Maximum Strictness) Option 2 (The Sweet Spot) Option 3 (Maximum Speed)
Yetus Phases Enabled mvninstall, compile, unit compile, unit
(Disabled: mvninstall) unit only
(Disabled: mvninstall, compile)
Step 1: Baseline maven install: master
master compilation: pre-patch master compilation: pre-patch (Skipped entirely)
Step 2: Patch Build maven install: patch
master compilation: patch master compilation: patch (Skipped entirely)
Step 3: Test Execution unit: patch unit: patch unit: patch
Estimated Maven Overhead ~20 minutes ~8 minutes 0 minutes
Pros Maximum safety. Fails early on missing dependencies. Drops JAR packaging time. Retains test-patch profile and early syntax failure detection and tracks compiler warning diffs. Absolute fastest pipeline.
Cons Very slow. Creates redundant JARs that unit doesn't strictly need. Very slight overhead to count warnings. Loses all warning tracking (e.g., deprecations). Syntax errors fail deep in the unit phase instead of failing early.

I would go for "Option 1 (Maximum Strictness)", even if I like the optimization in the "Option 2 (The Sweet Spot)":

  1. there could be many maven stages between compile and install, which we should cover (e.g. not sure, but maybe javadoc, etc.): using compile only could end up silently breaking things (and we're going to face them before a release)
  2. by running all the unit tests - as that's what we're trying to achieve now - we vote for full coverage, so we tend to accept longer runtimes for maximum strictness: if it's too bad, we can optimize later, but for now, we can afford this -> given the pace of Tez project, a few longer runs are absolutely okay, so from this point of view, I personally don't care about "Creates redundant JARs that unit doesn't strictly need."

regarding discontinuing Yetus: this points too far and needs community consensus: I mean that's okay, but the PR hits the local optima, I'm really satisfied with short-/mid-term

hm, wait, I just realized again that github actions cover the mvn clean install scenario by running:

mvn --batch-mode --no-transfer-progress clean install
-DskipTests -Dmaven.javadoc.skip=true

mvn --batch-mode --no-transfer-progress clean install -DskipTests -Dmaven.javadoc.skip=true

which is even better, as it runs on multiple platforms
considering the minimal time difference between these options (on my laptop):

mvn --batch-mode --no-transfer-progress clean install -DskipTests -Dmaven.javadoc.skip=true
...
[INFO] Total time:  50.257 s
mvn --batch-mode --no-transfer-progress clean install -DskipTests
...
[INFO] Total time:  49.779 s

so what about running full mvn install in github actions, and going for "Option 2 (The Sweet Spot)" in yetus?

To clarify, you'll need to configure GitHub Actions to run automatically on pull requests. I assume you're currently initiating them manually for each pull request..

yeah, and I think we should run the build workflow automatically, so it still points in the same direction

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

Run failed because of infra issue, will re-trigger

2026-05-18T18:06:26.552Z] ERROR: Caught signal TERM.

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

Aggarwal-Raghav commented May 19, 2026

In the latest run i.e 11, it is doing maven install: master and maven install: patch despite YETUS_ARGS+=("--plugins=all,-mvninstall"), after checking yetus,
for spotbugs: https://github.com/apache/yetus/blob/rel/0.15.1/precommit/src/main/shell/plugins.d/spotbugs.sh#L55-L57 and
for checkstyle: https://github.com/apache/yetus/blob/rel/0.15.1/precommit/src/main/shell/plugins.d/checkstyle.sh#L90-L95
it is adding mvninstall forcefully.

From tez-personality I can change the behaviour but I think that will be too hacky . So option 1 is the way i guess.

@tez-yetus
Copy link
Copy Markdown

💔 -1 overall

Vote Subsystem Runtime Logfile Comment
+0 🆗 reexec 0m 31s Docker mode activated.
_ Prechecks _
+1 💚 dupname 0m 0s No case conflicting files found.
+0 🆗 detsecrets 0m 0s detect-secrets was not available.
+0 🆗 shelldocs 0m 0s Shelldocs was not available.
+0 🆗 xmllint 0m 0s xmllint was not available.
+1 💚 @author 0m 0s The patch does not contain any @author tags.
-1 ❌ test4tests 0m 0s The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.
_ master Compile Tests _
+1 💚 mvninstall 4m 59s master passed
+1 💚 compile 1m 54s master passed
+1 💚 javadoc 1m 28s master passed
_ Patch Compile Tests _
+1 💚 mvninstall 5m 52s the patch passed
+1 💚 codespell 1m 48s The patch generated 0 new + 1 unchanged - 2 fixed = 1 total (was 3)
+1 💚 compile 3m 54s the patch passed
-1 ❌ javac 3m 54s /results-compile-javac-root.txt root generated 742 new + 0 unchanged - 34 fixed = 742 total (was 34)
+1 💚 blanks 0m 0s The patch has no blanks issues.
+1 💚 shellcheck 0m 1s The patch generated 0 new + 0 unchanged - 150 fixed = 0 total (was 150)
+1 💚 javadoc 1m 24s the patch passed
_ Other Tests _
+1 💚 unit 69m 59s root in the patch passed.
+1 💚 asflicense 0m 55s The patch does not generate ASF License warnings.
94m 17s
Subsystem Report/Notes
Docker ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/11/artifact/out/Dockerfile
Optional Tests dupname compile unit asflicense codespell detsecrets shellcheck shelldocs javac javadoc xmllint
uname Linux 01193934385a 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Build tool maven
Personality tez-personality.sh
git revision master / d0fa411
Default Java Eclipse Adoptium-21.0.11+10-LTS
Test Results https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/11/testReport/
Max. process+thread count 1468 (vs. ulimit of 5500)
modules C: . U: .
Console output https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/11/console
versions git=2.43.0 maven=3.9.15 codespell=2.4.1 shellcheck=0.11.0
Powered by Apache Yetus 0.15.1 https://yetus.apache.org

This message was automatically generated.

@tez-yetus
Copy link
Copy Markdown

💔 -1 overall

Vote Subsystem Runtime Logfile Comment
+0 🆗 reexec 0m 31s Docker mode activated.
_ Prechecks _
+1 💚 dupname 0m 0s No case conflicting files found.
+0 🆗 detsecrets 0m 0s detect-secrets was not available.
+0 🆗 shelldocs 0m 0s Shelldocs was not available.
+0 🆗 xmllint 0m 0s xmllint was not available.
+1 💚 @author 0m 0s The patch does not contain any @author tags.
-1 ❌ test4tests 0m 0s The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.
_ master Compile Tests _
+1 💚 mvninstall 5m 2s master passed
+1 💚 compile 1m 54s master passed
+1 💚 javadoc 1m 27s master passed
_ Patch Compile Tests _
+1 💚 mvninstall 3m 56s the patch passed
+1 💚 codespell 1m 45s The patch generated 0 new + 1 unchanged - 2 fixed = 1 total (was 3)
+1 💚 compile 3m 55s the patch passed
-1 ❌ javac 3m 55s /results-compile-javac-root.txt root generated 742 new + 0 unchanged - 34 fixed = 742 total (was 34)
+1 💚 blanks 0m 0s The patch has no blanks issues.
+1 💚 shellcheck 0m 1s The patch generated 0 new + 0 unchanged - 150 fixed = 0 total (was 150)
+1 💚 javadoc 1m 23s the patch passed
_ Other Tests _
+1 💚 unit 71m 6s root in the patch passed.
+1 💚 asflicense 0m 57s The patch does not generate ASF License warnings.
93m 29s
Subsystem Report/Notes
Docker ClientAPI=1.54 ServerAPI=1.54 base: https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/12/artifact/out/Dockerfile
Optional Tests dupname compile unit asflicense codespell detsecrets shellcheck shelldocs javac javadoc xmllint
uname Linux fe0c311cd56e 5.15.0-174-generic #184-Ubuntu SMP Fri Mar 13 18:41:50 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Build tool maven
Personality tez-personality.sh
git revision master / d0fa411
Default Java Eclipse Adoptium-21.0.11+10-LTS
Test Results https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/12/testReport/
Max. process+thread count 1359 (vs. ulimit of 5500)
modules C: . U: .
Console output https://ci-hadoop.apache.org/job/tez-multibranch/job/PR-498/12/console
versions git=2.43.0 maven=3.9.15 codespell=2.4.1 shellcheck=0.11.0
Powered by Apache Yetus 0.15.1 https://yetus.apache.org

This message was automatically generated.

@Aggarwal-Raghav
Copy link
Copy Markdown
Contributor Author

Because of https://github.com/apache/yetus/blob/dda07307f7eac00257a33ec61cac86dbde8d1e6d/precommit/src/main/shell/plugins.d/checkstyle.sh#L196-L200 the test-patch is hardcoded in checkstyle. Will revert back to test-patch from strict-warnings.

Sorry for running too many CI 😔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants