You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
We've been using the HCS acceptance tests as synthetic to occasionally test the end to end health of various network deployments and their associated mirrornodes.
We execute the tests with the following command:
./mvnw --batch-mode clean integration-test --projects hedera-mirror-test/ -P=acceptance-tests -Dcucumber.filter.tags="@Acceptance and not @SubscribeOnly" -Dspring.config.name=application-templated
This works really well in the vast majority of cases, but occasionally we get dependency download issues. The kicker is, when we get these failures, in almost all cases the HCS acceptance tests have actually passed. Here's a snippet:
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 147.641 s - in com.hedera.mirror.test.e2e.acceptance.AcceptanceTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- maven-jar-plugin:3.1.2:jar (default-jar) @ hedera-mirror-test ---
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/shared/file-management/3.0.0/file-management-3.0.0.pom
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/3.4.0/maven-archiver-3.4.0.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-archiver/3.4.0/maven-archiver-3.4.0.pom (4.6 kB at 176 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-archiver/4.1.0/plexus-archiver-4.1.0.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-archiver/4.1.0/plexus-archiver-4.1.0.pom (4.8 kB at 202 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.1.1/plexus-utils-3.1.1.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.1.1/plexus-utils-3.1.1.pom (5.1 kB at 211 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-io/3.1.1/plexus-io-3.1.1.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-io/3.1.1/plexus-io-3.1.1.pom (4.5 kB at 189 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-compress/1.18/commons-compress-1.18.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-compress/1.18/commons-compress-1.18.pom (18 kB at 729 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/47/commons-parent-47.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/commons/commons-parent/47/commons-parent-47.pom (78 kB at 2.9 MB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/iq80/snappy/snappy/0.4/snappy-0.4.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/iq80/snappy/snappy/0.4/snappy-0.4.pom (15 kB at 632 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/tukaani/xz/1.8/xz-1.8.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/tukaani/xz/1.8/xz-1.8.pom (1.9 kB at 83 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-interpolation/1.25/plexus-interpolation-1.25.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-interpolation/1.25/plexus-interpolation-1.25.pom (2.6 kB at 115 kB/s)
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.2.0/plexus-utils-3.2.0.pom
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.2.0/plexus-utils-3.2.0.pom (4.8 kB at 185 kB/s)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:50 min
[INFO] Finished at: 2020-08-17T06:03:22Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.1.2:jar (default-jar) on project hedera-mirror-test: Execution default-jar of goal org.apache.maven.plugins:maven-jar-plugin:3.1.2:jar failed: Plugin org.apache.maven.plugins:maven-jar-plugin:3.1.2 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-jar-plugin:jar:3.1.2 -> org.apache.maven.shared:file-management:jar:3.0.0: Failed to read artifact descriptor for org.apache.maven.shared:file-management:jar:3.0.0: Could not transfer artifact org.apache.maven.shared:file-management:pom:3.0.0 from/to central (https://repo.maven.apache.org/maven2): Transfer failed for https://repo.maven.apache.org/maven2/org/apache/maven/shared/file-management/3.0.0/file-management-3.0.0.pom: Connection reset -> [Help 1]
Solution
It would be nice if there was a way to execute the tests that only required dependencies needed for the tests. In the above snippet, it appears that the tests passed fine and the failure was triggered by a dependency that isn't required in this context.
We have some caching options we can look into on our end as well, but I thought I'd open this here as well in case there's anything we can do when executing the tests to limit the dependencies downloaded to only those needed by the acceptance tests.
The text was updated successfully, but these errors were encountered:
Yeah, it's failing when trying to package the classes into a jar after the tests. Since I don't think we're using that jar currently (we originally were trying to), we can switch this module to pom packaging so that it will skip this.
But I would highly recommend you switch to using the Docker image instead as it already contains all of the needed dependencies.
…967)"
Reverting changes for first attempt as it's easier to restart from the baseline than undo changes
This reverts commit 672326b.
Signed-off-by: Ian Jungmann <[email protected]>
)
* Fixing acceptance tests so that the jar is not always built (#967)
Signed-off-by: Ian Jungmann <[email protected]>
* Revert "Fixing acceptance tests so that the jar is not always built (#967)"
Reverting changes for first attempt as it's easier to restart from the baseline than undo changes
This reverts commit 672326b.
Signed-off-by: Ian Jungmann <[email protected]>
* Forcing jar to not build and surefire to run as part of integratio-test phase during acceptance tests
Signed-off-by: Ian Jungmann <[email protected]>
steven-sheehy
changed the title
Make HCS acceptance tests less depedent on maven downloads
Make HCS acceptance tests less dependent on Maven downloads
Sep 21, 2020
@beeradb You would still need to cache the .m2/repository directory in between builds to fully avoid all Maven downloads. This is just the nature of using Maven to run things.
Problem
We've been using the HCS acceptance tests as synthetic to occasionally test the end to end health of various network deployments and their associated mirrornodes.
We execute the tests with the following command:
./mvnw --batch-mode clean integration-test --projects hedera-mirror-test/ -P=acceptance-tests -Dcucumber.filter.tags="@Acceptance and not @SubscribeOnly" -Dspring.config.name=application-templated
This works really well in the vast majority of cases, but occasionally we get dependency download issues. The kicker is, when we get these failures, in almost all cases the HCS acceptance tests have actually passed. Here's a snippet:
Solution
It would be nice if there was a way to execute the tests that only required dependencies needed for the tests. In the above snippet, it appears that the tests passed fine and the failure was triggered by a dependency that isn't required in this context.
We have some caching options we can look into on our end as well, but I thought I'd open this here as well in case there's anything we can do when executing the tests to limit the dependencies downloaded to only those needed by the acceptance tests.
The text was updated successfully, but these errors were encountered: