Document that properties that change an application's beans are fixed at build time

[derkoe]

When running a native-built Spring Boot application on Kubernetes the liveness and readiness probes are not active (they both return a 404).

How to reproduce:

1. Go to start.spring.io and select Web, Actuator and GraalVM Native
2. Build a native image of your application (mvn spring-boot:build-image -Pnative)
3. Launch the application in Kubernetes (or set the appropriate environment when running locally docker run -it --rm -e KUBERNETES_SERVICE_HOST=localhost -e KUBERNETES_SERVICE_PORT=8080 -p 8080:8080 docker.io/library/demo:0.0.1-SNAPSHOT)
4. Open http://localhost:8080/actuator/health/liveness

Expected result - HTTP 200 with body {"status":"UP"}, actual result HTTP 404.

[snicoll]

The auto-detection of Kubernetes happen via auto-configuration and this needs to be specified at build-time when AOT prepares your application. In a native image, auto-configurations are detected and considered at build time.

Adding management.endpoint.health.probes.enabled in your configuration should fix the above.

[wilkinsona]

I think we could improve the docs a bit here. Perhaps in https://docs.spring.io/spring-boot/docs/3.0.x/reference/htmlsingle/#native-image.introducing-graalvm-native-images.key-differences-with-jvm-deployments or on the wiki. In the former we mention that the classpath is fixed, but we don't talk about (some) properties also being fixed and I think we should.

[derkoe]

@snicoll adding management.endpoint.health.probes.enabled=true works.

[derkoe]

I think we could improve the docs a bit here.

@wilkinsona I think it would be better for Spring users that these kind of features would work with native-image.
Another option would to document list of things that do not work or a list of things that are tested to be working. Both is not easy to do.

[wilkinsona]

I think it would be better for Spring users that these kind of features would work with native-image

Unfortunately, that's not easy due to Graal's closed-world assumptions. Furthermore, it would increase native image compile time and memory footprint. There's some more discussion related to this topic in spring-projects/spring-framework#29844. It's talking about profiles but configuration properties are largely the same problem.

Another option would to document list of things that do not work or a list of things that are tested to be working. Both is not easy to do

This issue will take a step in this direction.