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
