feat(ci): add integration test workflows (single-node + multinode)#6789
Open
warku123 wants to merge 4 commits into
Open
feat(ci): add integration test workflows (single-node + multinode)#6789warku123 wants to merge 4 commits into
warku123 wants to merge 4 commits into
Conversation
Pulls troninfra/troninfra-ci:latest from DockerHub on every PR/dispatch and runs the integration test suite against the FullNode.jar built from the PR. Uses JDK 8 inside the container so FullNode runs on the production runtime; JAVA_HOME_17 keeps Gradle on JDK 17 for the test tooling. Image is built and published from a separate repo (tron_integration-test/java-tron_integration-test) as part of that project's release pipeline (vX.Y.Z tag push).
Mirrors the single-node workflow but starts a 3-witness docker-compose stack via the integration-test image and runs the multinode test target against it. HOST_WORKDIR is set so the script's path-alignment logic resolves compose configs to host paths usable by the host docker daemon (DinD via socket mount). Builds the PR's FullNode.jar, wraps it in a local docker image that inherits from tronprotocol/java-tron:latest, and injects it into the multinode stack via TRON_IMAGE.
Both Integration Test workflows (Single Node / Multinode, Full) cover strictly more than the existing System Test runs. Drop System Test from the PR + push auto-trigger set so every commit doesn't pay the ~7 min runner cost twice for overlapping coverage. workflow_dispatch is kept so a regression suspect can still run stest manually from the Actions UI if needed. To re-enable for routine PR runs, uncomment the push + pull_request blocks at the top of the file.
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?
Adds two GitHub Actions workflows that gate PRs to
release_v4.8.2(anddevelop,release_**) with the modernized integration test suite, and removessystem-test.ymlsince the new workflows supersede it. Single-node and multinode workflows buildFullNode.jarfrom the PR, pulltroninfra/troninfra-ci:latest(public DockerHub image), and run the full integration test target against the freshly-built jar.The integration test image is published from a separate upstream-owned repo (
tron_integration-test/java-tron_integration-teston internal GitLab); its release pipeline pushesvX.Y.Z+:latesttags to DockerHub. This PR's workflows just consume that published image — no source access required.Why are these changes required?
The integration test suite (JUnit 5 + AssertJ on
TronTestBasefixtures) covers gRPC / HTTP / JSON-RPC, V2 staking, governance, smart contracts, event subscription, multi-witness consensus boundaries, and several other areas thatsystem-testeither didn't touch or asserted only weakly on. Up to now it has been a pre-release manual gate; wiring it into PR CI catches integration regressions before merge instead of after.This PR has been tested by:
Follow up
java.version.startsWith("1.8"). The workflow works around it by settingJAVA_HOMEto JDK 8 inside the container; the assertions themselves will be relaxed in a separate MR on the integration-test repo.workflow_dispatchlater.Extra details
pr-build) — net +5 min on PR wall-clock.troninfra/troninfra-ci:latestis public and rolls forward on eachvX.Y.Ztag from the integration-test repo. Workflows can be pinned to a specific tag if needed.