Experimented what happens if I swap the directory vs symlink.

Before:

% ls -la
total 16
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:51 .
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:51 ..
lrwxrwxrwx 1 kohsuke kohsuke   19 Apr 18 10:42 1 -> 2014-04-18_10-42-35
lrwxrwxrwx 1 kohsuke kohsuke   19 Sep 15 17:51 2 -> 2014-09-15_17-51-46
drwxrwxr-x 2 kohsuke kohsuke 4096 Apr 18 10:42 2014-04-18_10-42-35
drwxrwxr-x 2 kohsuke kohsuke 4096 Sep 15 17:51 2014-09-15_17-51-46
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastFailedBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastStableBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastSuccessfulBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnstableBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnsuccessfulBuild -> -1

After:

total 16
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:52 .
drwxrwxr-x 4 kohsuke kohsuke 4096 Sep 15 17:51 ..
drwxrwxr-x 2 kohsuke kohsuke 4096 Apr 18 10:42 1
drwxrwxr-x 2 kohsuke kohsuke 4096 Sep 15 17:51 2
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:52 2014-04-18_10-42-35 -> 1
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:52 2014-09-15_17-51-46 -> 2
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastFailedBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastStableBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    1 Sep 15 17:51 lastSuccessfulBuild -> 2
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnstableBuild -> -1
lrwxrwxrwx 1 kohsuke kohsuke    2 Apr 18 10:39 lastUnsuccessfulBuild -> -1

When I started, the build record did not load as I got the following error:

Sep 15, 2014 5:53:08 PM hudson.model.RunMap retrieve
WARNING: skipping non-build directory /files/kohsuke/ws/jenkins/jenkins/war/work/jobs/foo/builds/2014-09-15_17-51-46
Sep 15, 2014 5:53:08 PM hudson.model.RunMap retrieve
WARNING: skipping non-build directory /files/kohsuke/ws/jenkins/jenkins/war/work/jobs/foo/builds/2014-04-18_10-42-35

This is because of the way the Run.parseTimestampFromBuildDir method is implemented:

    /*package*/ static long parseTimestampFromBuildDir(@Nonnull File buildDir) 
            throws IOException, InvalidDirectoryNameException {
        try {
            if(Util.isSymlink(buildDir)) {
                // "Util.resolveSymlink(file)" resolves NTFS symlinks. 
                File target = Util.resolveSymlinkToFile(buildDir);
                if(target != null)
                    buildDir = target;
            }
            // canonicalization to ensure we are looking at the ID in the directory name
            // as opposed to build numbers which are used in symlinks
            // (just in case the symlink check above did not work)
            buildDir = buildDir.getCanonicalFile();
            return ID_FORMATTER.get().parse(buildDir.getName()).getTime();
        } catch (ParseException e) {
            throw new InvalidDirectoryNameException(buildDir);
        } catch (InterruptedException e) {
            throw new IOException("Interrupted while resolving symlink directory "+buildDir,e);
        }
    }

The canonical path in this case is build number and not timestamp, ID_FORMATTER.get().parse(...) fails and the above code results in InvalidDirectoryNameException.

The bottom line, the downgradable data migration through swapping dir vs symlink doesn't work.

So perhaps we are really back to the "provide downgrade script" idea.

Or we'll leave the complexity a bit by leaving the existing data as-is, and only add new builds in the new layout.

What if we make new build directory names different from all the existing patterns, for example b123? The migrator could leave old directories intact, and just add b123 -> 2014-04-18_10-42-35 kind of symlink in place, which leaves existing build records intact. Could something like that let us keep most of the code simplification while protecting existing build records?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to