[Geoserver-devel] GeoTools/GeoWebCache/GeoServer Meeting 2021-04-27

GeoTools/GeoWebCache/GeoServer PMC meeting - 2021-04-27### Attending#

Torben Barsballe

Kevin Smith

Jukka Rahkonnen

Jody Garnett

Andrea Aime

### Actions from last meeting:#

  • [DONE] AA: ask on the list about a 2.18.3 release manager

### Agenda#

  1. GSIP-202

  2. GWC release script

  3. Automatically close stale PRs?

  4. Build server issue

### Actions#

  • action: Kevin is going to fix gwc release.rb using xpath or something

  • action: Kevin will look at GWC website upload

  • action: Assign a new port for LDAP testing (since we made a new release)

## GSIP-202#

GSIP: https://github.com/geoserver/geoserver/wiki/GSIP-202

GeoServer homepage replacement, dedicated home page for workspaces, driven by freemarker but allow programmatic contribution. Remove version and commit numbers from pages accessible by anonymous users.

Discussion:

How do we discover workspaces? Right now they are not discoverable. Should they be? We should allow hiding them though, like with a security rule. Right now worksapce is adminable, but is it accessible? What about interaction with security subsystem?

How do security rules interact with the new page features, freemarker template configuration and with listing services and workspaces?

## GWC release script and docs#

Thanks to Ian for making the GT/GS release

Release script changes:

  • Change to pom “broke” release script, which was looking for a specific comment

  • Jody did a hack (ruby sub( search, replace ) vs sub! search, replace ← why why why

  • Action: Kevin is going to go fix it now using xpath or something

gwc website update?

  • cction: Kevin will look at this?

  • aside: documentation is done by copy, so old pages are not removed…

  • Can we delete everything before copy? Not so easy with S3 …

  • Going to github pages, limits run into 1GB limit, soft limit of 100GB bandwidth a month, soft limit of 10 builds an hour …

  • Q: Can we stay under 1GB?

  • Yes if we do stable, maintenance, latest …

  • It was around 500 MB last time we checked :slight_smile:

  • html docs zip is 92 MB

/tmp/geoserver-2.18.3 $ du -csh *

2,5M api

5,8M developer

20K LICENSE.md

4,0K README.txt

112M user

4,0K VERSION.txt

120M totale

Automatically close stale PRs?#

Danger zone, what will Andrea break next :slight_smile:

https://probot.github.io/apps/stale/

Can a bot do that? Yup…

  • Can we exclude a PR from bot clean up (say with a tag?)

Potential config:

Number of days of inactivity before an issue becomes stale

daysUntilStale: 90

Number of days of inactivity before a stale issue is closed

daysUntilClose: 14

Issues with these labels will never be considered stale

exemptLabels:

  • pinned

Label to use when marking an issue as stale

staleLabel: wontfix

Comment to post when marking an issue as stale. Set to false to disable

markComment: >

This issue has been automatically marked as stale because it has not had

recent activity. It will be closed if no further activity occurs. Thank you

for your contributions.

Comment to post when closing a stale issue. Set to false to disable

closeComment: >

This issue has been automatically closed because it has not had

recent activity. Please re-submit with updates if you want to resume work on this topic. Thank you for your contributions.

## Build server issues#

Should we set up different maven repositories to avoid conflicting updates of shared files, like

“/var/lib/jenkins/.m2/repository/org/geotools/gt-s3-geotiff/maven-metadata-local.xml”

See the *-java11 tests on jeknins for an example of how this could be configured

Port conflicts between concurrent tests:

  • H2 tests for example make use of a local test, there is a variable to disable these tests

LDAP test port issue?

  • action: we forgot to assign a new port when we made the most recent release!

Automatically close stale PRs?

Danger zone, what will Andrea break next :slight_smile:

https://probot.github.io/apps/stale/

Bot installed.

Build server issues#

Should we set up different maven repositories to avoid conflicting updates of shared files, like

“/var/lib/jenkins/.m2/repository/org/geotools/gt-s3-geotiff/maven-metadata-local.xml”

See the *-java11 tests on jeknins for an example of how this could be configured

Today the builds went back to red, with another metadata file corrupted.
Switched each of the GeoTools builds is now using its own local repo like the java11 ones do.
Seems to be working… finger crossed it stays that way :smiley:

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.

Build server issues#

Should we set up different maven repositories to avoid conflicting updates of shared files, like

“/var/lib/jenkins/.m2/repository/org/geotools/gt-s3-geotiff/maven-metadata-local.xml”

See the *-java11 tests on jeknins for an example of how this could be configured

Today the builds went back to red, with another metadata file corrupted.
Switched each of the GeoTools builds is now using its own local repo like the java11 ones do.
Seems to be working… finger crossed it stays that way :smiley:

Thanks Andrea, so if each build is using its own local repo - we can probably increasing parallel builds again?

Jody

···


Jody Garnett

Hi Jody,
yeah, at least at the GeoTools level. The Geoserver builds are still sharing the maven repository,
if you want to crank up the concurrency there too, I’d recommend doing the same.
It basically boils down to:

  • Make the workspace persist across runs (it was marked to be deleted, but the repo is in there)
  • Set maven to use a local maven repo (all JDK11 builds already do that too)

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.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.

I actually got stuck on the release process, with the geotools-release script:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install (default-install) on project gt-brewer: ArtifactInstallerException: Failed to install metadata org.geotools:gt-brewer/maven-metadata.xml: Could not parse metadata /var/lib/jenkins/.m2/repository/org/geotools/gt-brewer/maven-metadata-local.xml: in epilog non whitespace content is not allowed but got T (position: END_TAG seen ...</metadata>\nT... @12:2) -> [Help 1]

I think we are going to need the same approach for the release scripts also. 

···


Jody Garnett