fix(ci): build multinode test image from the PR's own distribution - #6905
Closed
warku123 wants to merge 2 commits into
Closed
fix(ci): build multinode test image from the PR's own distribution#6905warku123 wants to merge 2 commits into
warku123 wants to merge 2 commits into
Conversation
The multinode CI image step only swapped FullNode.jar into the base image, leaving stale module jars (common, chainbase, ...) from tronprotocol/java-tron:latest on the classpath. Any PR adding a cross-module API then crashes the node at Spring startup with NoSuchMethodError while the container stays Up, surfacing only as 'container tron-mn-node1 is unhealthy' (first hit by PR tronprotocol#82). Build the image lib/ from the PR's own dist zip instead, so all module jars and third-party dependencies come from one dependency resolution. This also auto-adapts to modules being added or renamed and to dependency-version bumps by the PR itself. Also copy /java-tron/logs out of the containers when collecting CI artifacts: docker logs only captures Logback stdout noise, while the real application log (tron.log) lives inside the container, without which node startup failures are undiagnosable.
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
1 participant
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 does this PR do?
dependency failed to start: container tron-mn-node1 is unhealthy..github/workflows/integration-test-multinode.ymlnow builds the image's/java-tron/libfrom the PR's own distribution zip (framework/build/distributions/java-tron-1.0.0.zip) instead of only copying FullNode.jar into the base image./gradlew clean build -x testactually does/java-tron/logs/(the real application log, tron.log) out of each container into the CI artifactsWhy are these changes required?
The image-build step only replaced FullNode.jar inside
tronprotocol/java-tron:latest, leaving the base image's stale module jars on the classpath. When a PR adds a cross-module API (for example framework code calling a new method in common), the node dies during Spring startup withjava.lang.NoSuchMethodError: org.tron.common.parameter.CommonParameter.isAdminRpcEnable()Zwhile the JVM process survives, so the container staysUpbut port 50051 is never bound; the healthcheck then exhausts its 180s window and the stack fails withcontainer tron-mn-node1 is unhealthy. Earlier PRs never hit this because they introduced no new cross-module method signatures.Building from the PR's own dist zip makes every jar (module jars and third-party dependencies) come from a single dependency resolution, and it auto-adapts to modules being added or renamed and to dependency-version bumps by the PR itself.
Additionally,
docker logsonly captures container stdout (Logback initialization noise); java-tron writes its real application log to/java-tron/logs/tron.loginside the container, which CI never collected, making this class of failure undiagnosable from CI artifacts.This PR has been tested by:
RpcApiService started, listening on 50051appeared in tron.log, and the test suite proceeded normallyFollow up
Extra details