Full Changelog 1.0.2

SecurityAccessProperties whitelists /actuator/**, but application.yml overrides that list with two exact paths, and a bound List replaces the default rather than adding to it. /actuator/health therefore matches only itself: /actuator/health/liveness and /actuator/health/readiness fall through to the authenticated rules and answer 401.

A kubelet counts 401 as a failed probe, so configuring liveness against the group would restart this service in a loop — which is why it is one of only two Java services in the platform still running without a liveness probe.

Both entries are needed: Ant /** does not match the bare path.

Also states management.endpoint.health.probes.enabled. Spring Boot enables the groups by itself only when it detects Kubernetes, so without this the endpoint a probe is aimed at 404s everywhere else — including in CI.

Reviewer was right that the previous commit treated a symptom. The Dockerfile located the jar with find …​ ! -name "*-plain.jar" because the name was unpredictable — but the name being unpredictable was itself the defect, and it had already grown a chain of workarounds around it.

version = '0.0.1-SNAPSHOT' is set, so Gradle produced ft-configs-service-0.0.1-SNAPSHOT.jar alongside a -plain.jar. Every consumer coped them then COPIED it to a fixed name, and Dockerfile.simple hardcoded that copy. Four moving parts, each silently wrong the day someone sets a real version — and the hardcoded name in Dockerfile.simple worked only by accident of that copy step.

Two lines in build.gradle remove all of it: bootJar { archiveFileName } fixes the name independently of the version, and jar { enabled = false } stops producing the plain jar, which was only ever there to be filtered out. This is an application, not a library, and there is no publishing block, so nothing consumed it.

Everything downstream is now direct rather than defensive: the Dockerfile COPYs the known path, and the workflows assert the file exists instead of searching for it.

Note this was not cosmetic. With the name pinned, the two cp "$JAR_PATH" build/libs/ft-configs-service.jar steps became a copy of a file onto itself, which cp refuses — leaving them would have broken both release pipelines.

Verified: build.gradle parses (gradlew help), all six workflows are still valid YAML, docker build --check clean on both Dockerfiles, and no find build/libs, -plain.jar filter or self-copy remains anywhere in the repository.