On Fri, May 24, 2019 at 1:35 AM Torben Barsballe via Geoserver-devel < [email protected]> wrote:
> Hello All, > > I'm going to go into a fair bit of detail relative to previous updates, so > that everyone has a clearer idea of exactly where we are at, the current > state, and what still needs to be done. > > *Server Configuration Changes* > First off, the new Jenkins instance has some differences from the old one: > > - It is, of course, running on a newer version of Jenkins, with > security updates installed, so some things may look a little different. > - Worker nodes now get spun up (and down) dynamically (via Amazon > SpotFleet). Ideally, this should give decent build performance without > having a large number of resources idling when there are no builds in > progress. This does result in a couple of compromises: > - If there are no jobs running for a while, all the worker nodes > will get shut down, and will take a little bit of time to start up when > the > next job is started > - It makes copying nightly artifacts back onto the master a little > more complicated, although this should be (mostly) working now. At > current, > artifacts get archived to the master node by Jenkins, then copied to the > location we use to host the nightly builds via a nightly cron job (so > they > will not show up immediately). I hope to change this to just ssh from > the > worker node to the hosting location on master if I can figure out how. > One > benefit of the new configuration is that artifacts are now also linked > directly from the nightly build that produced them. > - Configuration can not be assumed to be persistent between builds. > This will likely require the release jobs to be reconfigured somewhat. > > Ouch yes, that will definitely require the release scripts to be modified, as they are designed to work against a stable checkout. One possible approach is to make them create remote branches somewhere to persist the state of the work. > *Job Status:* > > I have been focusing on getting the main jobs for GeoTools, GeoWebCache, > and GeoServer working. > > - geoserver-<ver>, geoserver-<ver>-nightly and > geoserver-<ver>-live-docs are all working (except for > geoserver-master-live-docs, but this appears to be caused by a legitimate > error in the docs on master > - geowebcache-<ver> jobs are currently working (and deploying to > maven). geowebcache-<ver>-nightly jobs are not, as they assume they will > have access to the results of geowebcache-<ver>, which is no longer true. > They will need to be reconfigured. I'm currently looking into this. > - geotools-<ver> and geotools-<ver>-docs builds are building > successfully, but failing when they try to copy javadocs/docs > (respectively) to geotools.org. We need to aquire the key to > geotools.org and add it to jenkins before we can get these jobs > working (or disable doc uploads until we have the key). > > Who owns that key? > > - Most *-java11 jobs are working, since they generally don't need to > copy artifacts anywhere (java 11 has been configured in jenkins) > > I haven't looked at any of the other jobs yet > > - Cite and Online jobs aren't going to work until PostGIS is > configured on the worker nodes > > Makes sense. Is the worker node setup/configuration accessible so that one can help installing the packages? How are these managed, docker images? > - Release jobs require github and sourceforge keys, and may need some > other modifications > - I haven't looked at the geofence/geogig/geoscript jobs, and don't > know what is needed to get them working. > > The geofence job seems to be just failing to deploy artifacts with a 401, checked a nightly, it failed on a corrupt geotools jar. So, nothing special it seems, I've > Mailing list notifications also aren't working yet - a bit of > configuration still needs to be done on the build server before those will > be working (and its probably best to get most of the jobs working first > anyways, to avoid excess noise). > > The following points will require some coordination between various > project administrators: > > - If you have access to the geotools.org ssh key, please contact me so > we can add it to Jenkins. > - If you are an administrator for both the GeoTools and GeoServer > projects in GitHub, try and create a separate CI account with push > permissions to those projects and generate an ssh key for it, so that the > release jobs will be able to push artifacts to GitHub > - If you are an administrator for both the GeoTools and GeoServer > projects in SourceForge, try and create a separate CI account with push > permissions to those projects and generate an ssh key for it, so that the > release jobs will be able to push artifacts to SourceForge > > I can create these account. Are they going to be still managed by a single physical person (the one that creates the accounts and the keys), or are there better approaches? Searching the internet I've found nothing, suggestions welcomed. There are a couple of outstanding issues not discussed in the mail: - https is not setup yet, or not working ( https://build.geoserver.org/geoserver does not response, https://build.geoserver.org/ neither) and all links in the release are pointing to it. Setting up SSL should be quick (my devops colleagues say, eventually using a letsencrypt key), but if there are troubles, I can switch at least the download pages to use http instead? - All builds are failing while sending the final mail due to lack of a SMTP server. Thinking out loud, if needs be, I could create a gmail account for the purpose, and then I guess we could make Jenkins use the gmail smtp servers? Cheers Andrea == 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.it http://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.*
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
