geoserver / geoserver-cloud

Cloud Native GeoServer is GeoServer ready to use in the cloud through dockerized microservices.
http://geoserver.org/geoserver-cloud
Other
260 stars 79 forks source link

Image build error #568

Closed ghelobytes closed 1 month ago

ghelobytes commented 1 month ago

Build issue after pulling latest changes

After pulling the latest changes, we've been getting this error whenever trying to build the images:

$ make build-image
...
...
The command '/bin/sh -c java -XX:ArchiveClassesAtExit=application.jsa -Dspring.context.exit=onRefreshed -Dspring.profiles.active=standalone,datadir,offline -Dgeosever.backend.data-directory.location=/tmp/tmpdatadir -Dserver.port=0 -Dmanagement.server.port=0 org.springframework.boot.loader.JarLauncher' returned a non-zero code: 255
make: *** [build-image-geoserver] Error 255

We started experiencing this error after commit https://github.com/geoserver/geoserver-cloud/commit/2684f12bed11e1fe0b6cf52f8195c143512c613c. For reference, a comparison of before and after the commit: https://github.com/geoserver/geoserver-cloud/compare/9edb290bd55d9e0421e0e54ae0b173c6946baa6f...2684f12bed11e1fe0b6cf52f8195c143512c613c

Steps to reproduce

  1. Git clone git@github.com:geoserver/geoserver-cloud.git
  2. cd to geoserver-cloud
  3. Run make build-image

Expected result

Docker images of Geoserver cloud will be built successfully

Actual result

Getting the error:

The command '/bin/sh -c java -XX:ArchiveClassesAtExit=application.jsa -Dlog4j.debug=true -Dspring.context.exit=onRefreshed -Dspring.profiles.active=standalone,datadir,offline -Dserver.port=0 -Dmanagement.server.port=0 -Dgeosever.backend.data-directory.location=/tmp/tmpdatadir org.springframework.boot.loader.JarLauncher' returned a non-zero code: 255
make: *** [build-image-geoserver] Error 255

Workaround

As a temporary workaround commenting this specific lines in Dockerfiles of the services seems to work:

# Execute the CDS training run
# RUN java -XX:ArchiveClassesAtExit=application.jsa \
# -Dspring.context.exit=onRefreshed \
# -Dspring.profiles.active=standalone,offline \
# -Dserver.port=0 -Dmanagement.server.port=0 \
# org.springframework.boot.loader.JarLauncher
...
...
modified:   src/apps/geoserver/gwc/Dockerfile
modified:   src/apps/geoserver/restconfig/Dockerfile
modified:   src/apps/geoserver/wcs/Dockerfile
modified:   src/apps/geoserver/webui/Dockerfile
modified:   src/apps/geoserver/wfs/Dockerfile
modified:   src/apps/geoserver/wms/Dockerfile
modified:   src/apps/geoserver/wps/Dockerfile
modified:   src/apps/infrastructure/admin/Dockerfile
modified:   src/apps/infrastructure/config/Dockerfile
modified:   src/apps/infrastructure/discovery/Dockerfile
modified:   src/apps/infrastructure/gateway/Dockerfile

Proper fix?

This might have stem from the fact that the initial clone of the repo was done this way:

$ git clone git@github.com:geoserver/geoserver-cloud-config.git

instead of:

$ git clone --recurse-submodules git@github.com:geoserver/geoserver-cloud-config.git

While we were able to build without recursively cloning the submodules before, when this line was introduced in the Dockerfiles:

RUN java -XX:ArchiveClassesAtExit=application.jsa \
-Dspring.context.exit=onRefreshed \
-Dspring.profiles.active=standalone,offline \
-Dserver.port=0 -Dmanagement.server.port=0 \
org.springframework.boot.loader.JarLauncher

the config submodule started to matter.

We can confirm we haven't cloned the config submodule since the config subfolder is empty.

For existing cloned repo without the config submodule, run this to fix the build issue:

$ cd config
$ git submodule update --init
ghelobytes commented 1 month ago

Not really seeking any fix or resolution here. Just putting it up as a heads up. But maybe we can update the doc to explicitly say to clone with --recurse-submodules?

groldan commented 1 month ago

Hi @ghelobytes, thanks for reporting. I've made some improvements to the docs here 86f4ca68365653c6b9d4e292c2f2358341384378, including mentioning the usage in the README and dev guide.

Note though your assessment is correct, the config/ dir always mattered since it's a requirement for most Kubernetes deployments.

Cheers, I'm closing the ticket.