DockerNodeTest#testCopyFromNodeFolderToMissingPath fails #92
Description
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.
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 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.