Description
Spring Boot integration tests that use wiremock-spring-boot to dynamically override an HTTP-client base URL (via a @ConfigurationProperties bean)
started failing deterministically on the ubuntu-24.04 runner image released on 2026-05-13 (20260513.135). The same test, same commit, same JDK passes on
ubuntu-22.04 in a side-by-side run.
The failing test imports wiremock-spring-boot 3.9.0, Spring Boot 3.4.3, Temurin 21. WireMock starts and registers its dynamic port in the Spring
environment as foo.bar.service.url=http://localhost:<random> (visible in the log before the Spring banner), but the @ConfigurationProperties(prefix = "foo.bar.service") bean ends up bound to the static fallback URL from application-integration-test.yml (http://localhost:9008). The HTTP client then
hits localhost:9008 and the test times out.
Pinning the runner to ubuntu-22.04 fixes it on the same commit. Tested also on the previous ubuntu-24.04 image 20260413.86 — works there too.
Platforms affected
Runner images affected
Image version and build link
Failing images: ubuntu-24.04 20260513.135.3 and ubuntu-24.04 20260518.149.1
Last known working image: ubuntu-24.04 20260413.86 (active until 2026-05-13)
Builds are in a private repo but I can share excerpts on request:
- Failing CI run with
ubuntu-latest (=24.04): zertiban/zertiban-flow-service/actions/runs/26221076435
- Passing CI run on the same commit, pinned to
ubuntu-22.04: zertiban/zertiban-flow-service/actions/runs/26221076329
Both runs are from the exact same commit, exact same JDK (Temurin 21.0.11), only runs-on differs.
Is it regression?
Yes. Last green build for the affected test was on 2026-05-08, on image ubuntu-24.04 20260413.86. First red build was on 2026-05-13, on image ubuntu-24.04 20260513.135.3. All builds from 2026-05-13 onwards fail deterministically on at least three independent PRs in the same repo (and on other repos in the same org that use a similar Spring Boot + wiremock-spring-boot setup).
Expected behavior
A property added to the Spring Environment by wiremock-spring-boot's ContextCustomizer (which runs before context refresh, before bean
instantiation) is honored when binding @ConfigurationProperties. The HTTP client uses the dynamic WireMock URL.
This is the behavior on:
- ubuntu-22.04 (any current image, verified today)
- ubuntu-24.04 image
20260413.86 and earlier
- Local macOS 15, Temurin 21.0.11
Actual behavior
On ubuntu-24.04 images 20260513.135.3 and 20260518.149.1, the @ConfigurationProperties bean ends up bound to the static fallback URL
(http://localhost:9008 in our case) — even though the WireMock customizer has already added the dynamic URL to the Environment (we see the Adding property '...url=http://localhost:<random_port>' log line immediately before the Spring Boot Starting <Test> banner).
The HTTP call then connects to the static port and fails:
Caused by: org.springframework.web.reactive.function.client.WebClientRequestException:
finishConnect(..) failed: Connection refused: localhost/127.0.0.1:9008
*__checkpoint ⇢ Request to GET http://localhost:9008/v1/businesses/<uuid>/summary [DefaultWebClient]
Notable image diff 20260413.86 → 20260513.135:
- Kernel:
6.17.0-1010-azure → 6.17.0-1013-azure
- Java 21:
21.0.10+7 → 21.0.11+10 (we control JDK via setup-java + .java-version, ruled out as trigger — re-ran with 21.0.11 explicitly, same
failure)
- Network/system packages updated:
curl, openssh-client, iproute2, jq
Repro steps
-
Project: Spring Boot 3.4.3 + wiremock-spring-boot:3.9.0 + Temurin 21 (reproduces on both 21.0.6 and 21.0.11).
-
Configure a service URL via a @ConfigurationProperties bean with prefix foo.bar.service and a url field, defaulted in application.yml and
pinned to a static port (e.g. http://localhost:9008) in application-integration-test.yml.
-
In an integration test class, use:
@EnableWireMock({
@ConfigureWireMock(
name = "foo-bar-service",
baseUrlProperties = "foo.bar.service.url"
)
})
@SpringBootTest(...)
class FooBarIT { ... }
-
Add a @Test that triggers an HTTP call through the WebClient/Feign client built from foo.bar.service.url.
-
Run on runs-on: ubuntu-latest (which currently resolves to ubuntu-24.04 20260513.135.3+). The test fails with Connection refused to the static
fallback port, instead of the WireMock dynamic port.
-
Change to runs-on: ubuntu-22.04 with no other changes: test passes.
Happy to provide additional logs, a minimal public repro, or run any diagnostic the team would like.
Description
Spring Boot integration tests that use
wiremock-spring-bootto dynamically override an HTTP-client base URL (via a@ConfigurationPropertiesbean)started failing deterministically on the ubuntu-24.04 runner image released on 2026-05-13 (
20260513.135). The same test, same commit, same JDK passes onubuntu-22.04 in a side-by-side run.
The failing test imports
wiremock-spring-boot 3.9.0, Spring Boot 3.4.3, Temurin 21. WireMock starts and registers its dynamic port in the Springenvironment as
foo.bar.service.url=http://localhost:<random>(visible in the log before the Spring banner), but the@ConfigurationProperties(prefix = "foo.bar.service")bean ends up bound to the static fallback URL fromapplication-integration-test.yml(http://localhost:9008). The HTTP client thenhits
localhost:9008and the test times out.Pinning the runner to
ubuntu-22.04fixes it on the same commit. Tested also on the previous ubuntu-24.04 image20260413.86— works there too.Platforms affected
Runner images affected
Image version and build link
Failing images:
ubuntu-24.04 20260513.135.3andubuntu-24.04 20260518.149.1Last known working image:
ubuntu-24.04 20260413.86(active until 2026-05-13)Builds are in a private repo but I can share excerpts on request:
ubuntu-latest(=24.04): zertiban/zertiban-flow-service/actions/runs/26221076435ubuntu-22.04: zertiban/zertiban-flow-service/actions/runs/26221076329Both runs are from the exact same commit, exact same JDK (Temurin 21.0.11), only
runs-ondiffers.Is it regression?
Yes. Last green build for the affected test was on 2026-05-08, on image
ubuntu-24.04 20260413.86. First red build was on 2026-05-13, on imageubuntu-24.04 20260513.135.3. All builds from 2026-05-13 onwards fail deterministically on at least three independent PRs in the same repo (and on other repos in the same org that use a similar Spring Boot + wiremock-spring-boot setup).Expected behavior
A property added to the Spring
Environmentbywiremock-spring-boot'sContextCustomizer(which runs before context refresh, before beaninstantiation) is honored when binding
@ConfigurationProperties. The HTTP client uses the dynamic WireMock URL.This is the behavior on:
20260413.86and earlierActual behavior
On ubuntu-24.04 images
20260513.135.3and20260518.149.1, the@ConfigurationPropertiesbean ends up bound to the static fallback URL(
http://localhost:9008in our case) — even though the WireMock customizer has already added the dynamic URL to the Environment (we see theAdding property '...url=http://localhost:<random_port>'log line immediately before the Spring BootStarting <Test>banner).The HTTP call then connects to the static port and fails:
Notable image diff
20260413.86 → 20260513.135:6.17.0-1010-azure → 6.17.0-1013-azure21.0.10+7 → 21.0.11+10(we control JDK viasetup-java+.java-version, ruled out as trigger — re-ran with 21.0.11 explicitly, samefailure)
curl,openssh-client,iproute2,jqRepro steps
Project: Spring Boot 3.4.3 +
wiremock-spring-boot:3.9.0+ Temurin 21 (reproduces on both 21.0.6 and 21.0.11).Configure a service URL via a
@ConfigurationPropertiesbean with prefixfoo.bar.serviceand aurlfield, defaulted inapplication.ymlandpinned to a static port (e.g.
http://localhost:9008) inapplication-integration-test.yml.In an integration test class, use:
Add a
@Testthat triggers an HTTP call through the WebClient/Feign client built fromfoo.bar.service.url.Run on
runs-on: ubuntu-latest(which currently resolves to ubuntu-24.0420260513.135.3+). The test fails withConnection refusedto the staticfallback port, instead of the WireMock dynamic port.
Change to
runs-on: ubuntu-22.04with no other changes: test passes.Happy to provide additional logs, a minimal public repro, or run any diagnostic the team would like.