That error shows up on pretty much all of the jobs (including the
successful ones) - I think it is a side effect of running on dynamic
workers, and is safe to ignore, althoguh I'm not certain - it didn't seem
to be affecting job execution, so I haven't looked too closely at it yet.

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.

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

Reply via email to