Hi Andrea Yeah, did notice run.sh expects to be a level higher. I feel like it would make just as much sense to reconfigure run.sh to work from within the cite-tools repo as it would to put it in its own repo (there's already enough repos involved in the cite build as it is), but if you think adding another repo would be easier, then thats fine by me.
The assembly/setup portion seems like something that could be added to run.sh (perhaps with some checks to see if things are already set up), or included in the cite build config on jenkins. As for ports, sed during execution seems sensible to me. A workaround for the geoserver checkout seems like a good idea to me as well. I believe it is possible to download subfolders of a repository via github, so that might be one way to go. Take a look at this <https://stackoverflow.com/a/18194523/5775728> StackOverflow post. Cheers, Torben On Sun, Jun 2, 2019 at 2:08 AM Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi Torben, > I had a look at tried to understand how the tools work. > The run.sh is not meant to be part of the cite tools repository, it > actually needs to be in a different repo > and work a directory level up compared to the tools. > > It is also supposed to have a "one time" setup that are part of the > instructions at the top, which > would checkout the cite tools and geoserver itself (in order to get the > data directories) and work from there. > > The forms submodule (coming from Justin's checkouts) is also in need to be > modified to change the ports. > > I've also noticed that the workspaces do not seem to be available after > builds, which makes things difficult to debug, > probably due to the worker node disappearing after the build is done. > > Maybe it's possible to resuscitate the cite tests, but I'm guessing it > would require some extra effort, thinking out loud: > > - Put run.sh in its own repository > - Clone the forms and update it (or just sed it during execution to > change the ports) > - Create an assembly for the data dirs during the geoserver build so > that we don't have to clone all geoserver, or use some form of partial > checkout > > I'm also looking into just switching to the newer docker based teamengine > architecture, but it seems it does not > support a one shot execution of the test suites, it would start the web > interface of the teamengine instead: > https://github.com/opengeospatial/teamengine-docker/issues/11 > > 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.* >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
