Replies inline. I've cut out some of the extraneous content to reduce clutter
On Fri, May 24, 2019 at 3:51 AM Andrea Aime <[email protected]> wrote: > On Fri, May 24, 2019 at 1:35 AM Torben Barsballe via Geoserver-devel < > [email protected]> wrote: > >> >> - 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. > > That seems like a reasonable solution (and honestly, is probably better practice than having state stored on the CI server anyway). > >> - 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? > That is one key that I know Planet Federal doesn't own. I think we had to get in touch with OSGeo to get the key last time, but I'm not certain - thats part of the reason why I am bringing it up. I'll dig into old list emails and see if I can track a bit more info down. > >> - 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? > > They are AWS AMIs with a script that runs to install the packages. The worker nodes are one of the things that I didn't set up, and they aren't yet accessible (I can't even get into them right now). I might have a bit more information on this on Tuesday - the person who set the nodes up is on holiday until then. > >> - 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 > >> >> 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. > Thanks. I've got no good ideas either, and would also welcome suggestions. > > 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? > > Right, forgot about that one. It just hasn't been set up yet, still a todo. > > - 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? > > While the builds throw an error, this isn't resulting in a failing status. Most of the GeoServer jobs show success even thought they throw the SMTP error. I presume we had a SMTP server set up somewhere for the old server and can probably use a similar solution here, but thats just another thing that no one's has time to look into yet. Cheers, Torben
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
