[Feature] Java build efficiency improvement suggestions

[wl4g]

Scenario:
If both projectA and projectB depend on projectC, and these may be maintained by two separate teams, then:

Optimization 1:
If a git pull shows no updates, reuse the previous build artifacts directly.

Optimization 2:
Since multiple teams maintain the projects and builds happen frequently, when multiple builds are triggered concurrently, subsequent tasks can wait for the first triggered task to finish building projectC before continuing their parallel builds.

Summary:
This approach implements phased serialization combined with phased parallelism, which is similar to how generational garbage collection acceleration algorithms work.

[lilianzhu]

Optimization 1:
If there is no code update, why is a rebuild necessary? In what scenarios would this happen?

Optimization 2:
If there are two projects maintained by two different teams, I understand there would be two separate workflows. It’s difficult to control concurrency or serialization between tasks across different workflows. If you know of any open-source tools that handle this well, please feel free to share.
@wl4g

[wl4g]

The scenario for Optimization 1 is quite clear. More precisely, this situation usually refers to a common project (like the projectC mentioned above). For example, when projectA is updated and needs to release the corresponding serviceA, but projectC has no updates, there is no need to rebuild projectC during the build process. Only projectA needs to be built. This approach can save a significant amount of build time and greatly accelerate the process.

[wl4g]

However, up to now (version 1.14.0), although Zadig does not have a dedicated optimization for this situation, I have already implemented build skipping in a custom build script. I am sharing the script below for others who might find it useful:

#!/bin/bash
set -e
cd $WORKSPACE/projectC/

# Enhanced check, skip current build step if commitId is not updated.
export COMMIT_ID="$projectC_COMMIT_ID"
export LAST_COMMIT_ID="$(cat $WORKSPACE/.projectC_LAST_COMMIT_ID 2>/dev/null)"

echo "The current commitId: $COMMIT_ID"
echo "The last commitId: $LAST_COMMIT_ID"

if [ "$COMMIT_ID" != "$LAST_COMMIT_ID" ]; then
  echo "updated, new building ...."
  mvn clean install -DskipTests -Dmaven.test.skip=true -T 2C

  echo "Update the commmitId for $COMMIT_ID ..."
  echo $COMMIT_ID > $WORKSPACE/.projectC_LAST_COMMIT_ID
else
  echo "No update, using last build cache ...."
fi

Note: To make the above enhanced check effective, the "Cache Directory Rule" should be set to $PROJECT/$WORKFLOW.

[wl4g]

Regarding Optimization 2, this requirement is actually quite common. The reason is less related to enterprise workflows and more tied to the engineering complexity of Java—often referred to as a "dinosaur" language. Typically, building and releasing a Spring Boot service may involve dozens of dependent projects.

Putting aside the isolation between workflows for a moment, if different teams maintain these projects but share the same Zadig instance, from the users' perspective, it can be seen as a single black box. If they perform n builds daily, and among them m builds have overlapping execution times, this scenario fits perfectly. The later-triggered builds can wait for the first build to finish building projectC (this is phased serialization), and then continue with parallel builds.

As @lilianzhu mentioned, sharing between different workflows is difficult, and I mostly agree with that. However, I see this as a current limitation of Zadig regarding this practical requirement. On the other hand, many times, such as with serviceA and serviceB, the same team maintains multiple microservices. To ensure consistent interface releases across them, simultaneous build and release is necessary, making this optimization even more practical.