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
With the 1.2.1 release the test DockerNodeTest#testCopyFromNodeFolderToMissingPath is failing:
testCopyFromNodeFolderToMissingPath(org.wildfly.extras.sunstone.api.impl.docker.DockerNodeTest) Time elapsed: 0.257 sec <<< FAILURE!
java.lang.AssertionError: File DockerNodeTest-workdir/folder/subfolder/aa/hello.world should exist
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.wildfly.extras.sunstone.api.impl.docker.DockerNodeTest.assertFileExistsInWorkDir(DockerNodeTest.java:564)
at org.wildfly.extras.sunstone.api.impl.docker.DockerNodeTest.testCopyFromNodeFolderToMissingPath(DockerNodeTest.java:478)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
The failure is valid. The test copies directory /opt/a/ from the container into workdir/folder/subfolder/ which does not exist. The directory workdir/folder/subfolder is correctly created. However, the /opt/a/ directory contains three directories aa, bb and cc. Those contain the files that the test checks for in the end. The test expects that the three directories are copied under workdir/folder/subfolder. However, the aa directory is truncated to a, and therefore the files under aa are not found on the expected path.
On the other hand, the copying logic contains a piece where, if the local directory does not exist (which it does not in this case), a string equal to remote target directory name is stripped from the local directory.
The stripping logic clearly exists to trim extra preceding directories from the local target. The tar archive is meant to be created with entries that look like a/aa/<file>, but it is instead created with entries that look like aa/<file>.
The relevant code in Sunstone hasn't changed since 1.2.0. I don't recall the test failing in the past, but it is now failing with Sunstone 1.2.0 as well as 1.0.0. This must be some sort of interaction between newer Docker versions and JClouds APIs.
The text was updated successfully, but these errors were encountered:
With the 1.2.1 release the test
DockerNodeTest#testCopyFromNodeFolderToMissingPath
is failing:The failure is valid. The test copies directory
/opt/a/
from the container intoworkdir/folder/subfolder/
which does not exist. The directoryworkdir/folder/subfolder
is correctly created. However, the/opt/a/
directory contains three directoriesaa
,bb
andcc
. Those contain the files that the test checks for in the end. The test expects that the three directories are copied underworkdir/folder/subfolder
. However, theaa
directory is truncated toa
, and therefore the files underaa
are not found on the expected path.On the other hand, the copying logic contains a piece where, if the local directory does not exist (which it does not in this case), a string equal to remote target directory name is stripped from the local directory.
https://github.com/wildfly-extras/sunstone/blob/master/core/src/main/java/org/wildfly/extras/sunstone/api/impl/docker/DockerNode.java#L474
https://github.com/wildfly-extras/sunstone/blob/master/core/src/main/java/org/wildfly/extras/sunstone/api/impl/SshUtils.java#L79
I think the current behaviour shows a bug somewhere in:
https://github.com/wildfly-extras/sunstone/blob/master/core/src/main/java/org/wildfly/extras/sunstone/api/impl/docker/DockerNode.java#L471
The stripping logic clearly exists to trim extra preceding directories from the local target. The tar archive is meant to be created with entries that look like
a/aa/<file>
, but it is instead created with entries that look likeaa/<file>
.The relevant code in Sunstone hasn't changed since 1.2.0. I don't recall the test failing in the past, but it is now failing with Sunstone 1.2.0 as well as 1.0.0. This must be some sort of interaction between newer Docker versions and JClouds APIs.
The text was updated successfully, but these errors were encountered: