> 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
