dnusbaum
I did some additional tests and found out that the issue I found, was already present, but was outlined by another one (or a behavior change?) introduced in 2.91. Here are the details:
Issue 1: tar breaking the symlinks (not a regression, at least since 2.60)
This is the issue I initially reported, except it's not a regression. I found out that a symlink to a directory is tarred into a directory. Here is a unit test outlining that. Note that the test is red since 2.60 at least:
import hudson.FilePath;
import org.junit.Assert;
import org.junit.Rule;
import org.junit.rules.TemporaryFolder;
import java.io.IOException;
import java.io.OutputStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
public class Test {
@Rule
public TemporaryFolder folder= new TemporaryFolder();
@org.junit.Test
public void aSymlinkToADirectoryFails() throws IOException, InterruptedException {
Path folderToTar = folder.newFolder().toPath();
Path subdirectory = Files.createDirectory(folderToTar.resolve("subdirectory"));
Path targetDirectory = subdirectory.resolve("1");
Files.createDirectory(targetDirectory);
Files.createFile(targetDirectory.resolve("oneFile"));
Path link = Files.createSymbolicLink(subdirectory.resolve("link"), Paths.get("1"));
Assert.assertTrue(Files.isSymbolicLink(link));
Path tarFile = folderToTar.resolve("archive.tar");
FilePath tarFilePath = new FilePath(tarFile.toFile());
try (OutputStream os = tarFilePath.write()) {
new FilePath( folderToTar.toFile()).tar(os, "**/*");
}
Path untarredFolder = folder.getRoot().toPath().resolve("untarredFolder");
tarFilePath.untar(new FilePath(untarredFolder.toFile()), FilePath.TarCompression.NONE);
Assert.assertTrue(Files.isSymbolicLink(untarredFolder.resolve("subdirectory/link")));
}
@org.junit.Test
public void aSymlinkToAFileWorks() throws IOException, InterruptedException {
Path folderToTar = folder.newFolder().toPath();
Path subdirectory = Files.createDirectory(folderToTar.resolve("subdirectory"));
Path targetFile = subdirectory.resolve("1");
Files.createFile(targetFile);
Path link = Files.createSymbolicLink(subdirectory.resolve("link"), Paths.get("1"));
Assert.assertTrue(Files.isSymbolicLink(link));
Path tarFile = folderToTar.resolve("archive.tar");
FilePath tarFilePath = new FilePath(tarFile.toFile());
try (OutputStream os = tarFilePath.write()) {
new FilePath( folderToTar.toFile()).tar(os, "**/*");
}
Path untarredFolder = folder.getRoot().toPath().resolve("untarredFolder");
tarFilePath.untar(new FilePath(untarredFolder.toFile()), FilePath.TarCompression.NONE);
Assert.assertTrue(Files.isSymbolicLink(untarredFolder.resolve("subdirectory/link")));
}
}
Issue 2: behavior change in 2.91
The shelve plugin is using the tar function we just saw to archive job directories. Upon unarchiving, a job directory looks therefore like this:
Instead of:
The thing is, before 2.91, when launching a new run of the job, Jenkins was somehow capable of deleting those directories and recreating the symlinks.
Now, it is unable of doing so:
As the job directory is not supposed to be in this state, I can understand that this behavior change is not necessarily a bug. However the first issue looks like a bug.
dnusbaum
I did some additional tests and found out that the issue I found, was already present, but was outlined by another one (or a behavior change?) introduced in 2.91. Here are the details:
Issue 1: tar breaking the symlinks (not a regression, at least since 2.60)
This is the issue I initially reported, except it's not a regression. I found out that a symlink to a directory is tarred into a directory. Here is a unit test outlining that. Note that the test is red since 2.60 at least:
Issue 2: behavior change in 2.91
The shelve plugin is using the tar function we just saw to archive job directories. Upon unarchiving, a job directory looks therefore like this:
Instead of:
The thing is, before 2.91, when launching a new run of the job, Jenkins was somehow capable of deleting those directories and recreating the symlinks.
Now, it is unable of doing so:
As the job directory is not supposed to be in this state, I can understand that this behavior change is not necessarily a bug. However the first issue looks like a bug.