I've cleared out all the non-symlink lastSuccessful and lastStable directories. Jenkins should be able to populate the symlinks properly now - this warning shouldn't show up anymore:
in builds/lastSuccessfulBuild /var/lib/jenkins/jobs/geoserver-release/lastSuccessful failed java.nio.file.DirectoryNotEmptyException: /var/lib/jenkins/jobs/geoserver-release/lastSuccessful If you continue to see it on some jobs, let me know. Cheers, Torben On Wed, Jun 12, 2019 at 10:23 AM Torben Barsballe < [email protected]> wrote: > > There are some jenkins bug reports >> <https://issues.jenkins-ci.org/browse/JENKINS-48862> about the error >> which suggest it may be caused by having actual directories instead of >> symlinks for the lastSuccessful and lastFailed (perhaps caused by a >> backup/restore) - I'll take a look at the master and see if that is the >> case. >> >> Turned out this indeed was the case - lastSuccessful is a directory > instead of a symlink, due to the restore from backup when we made the > server. > Removing the directory on the geoserver-master job cleared up the issue > there. > > I'll wait until the release is done (so I don't delete anything that might > be important), and then clean up the rest of the directories. > > Torben > > > >> Torben >> >> On Wed, Jun 12, 2019 at 10:07 AM Jody Garnett <[email protected]> >> wrote: >> >>> That is an interesting approach, it is preferable to rebuilding the >>> artifacts for publication which was my next thought. >>> >>> One word of caution is the two failures which appear at the start of >>> each console log: >>> >>> ln builds/lastSuccessfulBuild >>> /var/lib/jenkins/jobs/geoserver-release/lastSuccessful failed >>> java.nio.file.DirectoryNotEmptyException: >>> /var/lib/jenkins/jobs/geoserver-release/lastSuccessful >>> at >>> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242) >>> at >>> sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108) >>> at java.nio.file.Files.deleteIfExists(Files.java:1165) >>> at hudson.Util.createSymlink(Util.java:1193) >>> at hudson.model.Run.createSymlink(Run.java:1955) >>> at hudson.model.Run.updateSymlinks(Run.java:1936) >>> at hudson.model.Run.execute(Run.java:1814) >>> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) >>> at hudson.model.ResourceController.execute(ResourceController.java:97) >>> at hudson.model.Executor.run(Executor.java:429) >>> ln builds/lastStableBuild >>> /var/lib/jenkins/jobs/geoserver-release/lastStable failed >>> java.nio.file.DirectoryNotEmptyException: >>> /var/lib/jenkins/jobs/geoserver-release/lastStable >>> at >>> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242) >>> at >>> sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108) >>> at java.nio.file.Files.deleteIfExists(Files.java:1165) >>> at hudson.Util.createSymlink(Util.java:1193) >>> at hudson.model.Run.createSymlink(Run.java:1955) >>> at hudson.model.Run.updateSymlinks(Run.java:1937) >>> at hudson.model.Run.execute(Run.java:1814) >>> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) >>> at hudson.model.ResourceController.execute(ResourceController.java:97) >>> at hudson.model.Executor.run(Executor.java:429) >>> >>> >>> Any ideas? >>> >>> >>> -- >>> Jody Garnett >>> >>> >>> On Wed, 12 Jun 2019 at 09:41, Torben Barsballe < >>> [email protected]> wrote: >>> >>>> For a slightly more stable URL, >>>> https://build.geoserver.org/view/release/job/geoserver-release/lastSuccessfulBuild/artifact/release/ >>>> avoids >>>> the job number. >>>> >>>> Currently, its not possible to upload artifacts directly to >>>> https://build.geoserver.org/geoserver/releases/ for security reasons >>>> (short version - workers don't have authorization to scp to master). I >>>> looked into that when setting up the nightly builds, and didn't have much >>>> luck getting around the issue (for now, the workaround has been to archive >>>> the artifacts, and have a cron job copy them from the archive location to >>>> /geoserver). I'd still like to find a way around this, but don't really >>>> have a timeline. >>>> >>>> For the releases, the archived artifact location should work fine. The Copy >>>> Artifact Plugin >>>> <https://wiki.jenkins.io/display/JENKINS/Copy+Artifact+Plugin> >>>> (installed) can let downstream jobs (e.g. geoserver-release-publish) copy >>>> the artifacts from an upstream job directly through Jenkins. >>>> >>>> Torben >>>> >>>> >>>> On Tue, Jun 11, 2019 at 10:42 PM Jody Garnett <[email protected]> >>>> wrote: >>>> >>>>> The artifacts are attached to the build job for now: >>>>> >>>>> >>>>> https://build.geoserver.org/view/release/job/geoserver-release/240/artifact/release/2.14.4/ >>>>> >>>>> Not quite sure how to reproduce the logic to transfer them to a more >>>>> stable URL (other than uploading to source forge). >>>>> -- >>>>> Jody Garnett >>>>> _______________________________________________ >>>>> Geoserver-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>>> >>>>
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
