Search before asking
What happened
After #18213 ([Chore] Unit-Test performance optimize) split the CI unit test into separate install and verify steps, multiple modules fail intermittently with missing transitive dependencies. The failures are not reproducible locally.
Each CI run fails in a different module with dependency resolution errors:
| Commit |
Failed module |
Error |
756f2f248b |
dolphinscheduler-spi |
NoClassDefFoundError: com/fasterxml/jackson/core/type/TypeReference |
0055001703 |
dolphinscheduler-dao |
package org.apache.commons.collections4 does not exist |
Meanwhile, runs in between (e.g. 5f11cc2d28, dd8857b84c65, 5c85e15a8b96) pass successfully — indicating the issue is intermittent.
What you expected to happen
All module unit tests should pass consistently in CI.
How to reproduce
Cannot be reproduced locally. Running the same two-step command locally always succeeds:
./mvnw install -pl dolphinscheduler-spi -am -Dmaven.test.skip=true
./mvnw verify -pl dolphinscheduler-spi
# Passes locally — the transitive dependencies resolve correctly from ~/.m2
The failure only occurs in GitHub Actions, suggesting a CI-specific environmental issue.
Anything else
CI change introduced by #18213:
Before #18213, the CI ran tests in a single step with -am:
./mvnw verify -pl "$module" -am
After #18213, it was split into two steps:
# Step 1: install dependencies
./mvnw install -pl "$module" -am -Dmaven.test.skip=true
# Step 2: run tests (without -am)
./mvnw verify -pl "$module"
Analysis:
- The
install -am step succeeds and installs all upstream modules (jar + pom) into ~/.m2/repository.
- The
verify step (without -am) should resolve transitive dependencies from the local repo — and it does locally.
- In CI,
actions/cache@v5 restores a Maven cache keyed by hashFiles('**/pom.xml'). When the cache is stale or partially restored (e.g. due to a cache key change from pom.xml modifications), the verify step may fail to resolve transitive dependencies that were not freshly downloaded.
- The intermittent nature (different modules fail on different runs, with successes in between) strongly suggests the issue is related to Maven cache state inconsistency on CI runners, not a deterministic build configuration bug.
Affected CI runs:
Suggested fix:
- Restore
-am in the verify step to ensure Maven resolves the full dependency graph in reactor mode, independent of cache state, or
- Add a cache invalidation / cleanup step before the verify phase
Version
dev
Are you willing to submit PR?
Code of Conduct
Search before asking
What happened
After #18213 (
[Chore] Unit-Test performance optimize) split the CI unit test into separateinstallandverifysteps, multiple modules fail intermittently with missing transitive dependencies. The failures are not reproducible locally.Each CI run fails in a different module with dependency resolution errors:
756f2f248bNoClassDefFoundError: com/fasterxml/jackson/core/type/TypeReference0055001703package org.apache.commons.collections4 does not existMeanwhile, runs in between (e.g.
5f11cc2d28,dd8857b84c65,5c85e15a8b96) pass successfully — indicating the issue is intermittent.What you expected to happen
All module unit tests should pass consistently in CI.
How to reproduce
Cannot be reproduced locally. Running the same two-step command locally always succeeds:
./mvnw install -pl dolphinscheduler-spi -am -Dmaven.test.skip=true ./mvnw verify -pl dolphinscheduler-spi # Passes locally — the transitive dependencies resolve correctly from ~/.m2The failure only occurs in GitHub Actions, suggesting a CI-specific environmental issue.
Anything else
CI change introduced by #18213:
Before #18213, the CI ran tests in a single step with
-am:./mvnw verify -pl "$module" -amAfter #18213, it was split into two steps:
Analysis:
install -amstep succeeds and installs all upstream modules (jar + pom) into~/.m2/repository.verifystep (without-am) should resolve transitive dependencies from the local repo — and it does locally.actions/cache@v5restores a Maven cache keyed byhashFiles('**/pom.xml'). When the cache is stale or partially restored (e.g. due to a cache key change from pom.xml modifications), theverifystep may fail to resolve transitive dependencies that were not freshly downloaded.Affected CI runs:
Suggested fix:
-amin theverifystep to ensure Maven resolves the full dependency graph in reactor mode, independent of cache state, orVersion
dev
Are you willing to submit PR?
Code of Conduct