== GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.ithttp://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.
run the “bin” package, did a bit of quick random testing:
starts up
layers present and accounted for
preview works, GFI in preview works, tried out groups and rasters
created groups of existing layer groups, verified it works
tested a few of caps links, tried out workspace specific links, that also appears to be fine
bit of style editing, worked
No anomalies found
Cheers
Andrea
···
Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.ithttp://twitter.com/geosolutions_it ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.
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 (installed) can let downstream jobs (e.g. geoserver-release-publish) copy the artifacts from an upstream job directly through Jenkins.
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)
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 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.
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)
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 (installed) can let downstream jobs (e.g. geoserver-release-publish) copy the artifacts from an upstream job directly through Jenkins.
There are some jenkins bug reports 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.
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)
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 (installed) can let downstream jobs (e.g. geoserver-release-publish) copy the artifacts from an upstream job directly through Jenkins.
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.
There are some jenkins bug reports 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.
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)
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 (installed) can let downstream jobs (e.g. geoserver-release-publish) copy the artifacts from an upstream job directly through Jenkins.