mhoennigandClaude Opus 5
c0e52cb95f
werkator build succeeded after 00:36
The programmatic PostgreSQLContainer was one way to ask werkdock for a database. The way most projects actually ask is a jdbc:tc URL, where Testcontainers is the JDBC driver and no Java code mentions a container at all. This adds that form, as a Spring Boot application whose application.yml holds the URLs, and leaves the programmatic test class untouched — the two take different paths through Testcontainers and are therefore two questions, not one. JdbcUrlDatabaseTest asks four of them: the configured URL connects, the init script named in it has run, the server listens on a port that is not the container's own, and a second URL is a second server. All nine tests pass against werkdock, on a developer machine and in CI on the managed webspace, and werkdock needed no change for any of it: a JDBC init script travels over the connection, so it does not want the archive endpoint werkdock has yet to grow. TC_DAEMON=true is in the URLs on purpose. Without it Testcontainers stops the database when the last connection closes, and a connection pool closes connections whenever it likes. Versions now come from Spring Boot's BOM, so Testcontainers moved from 1.19.3 to 1.21.4 — deliberately, and both test classes pass on it. A declared version does not hold against a platform constraint in Gradle; pretending otherwise in a comment would have been worse than saying which version actually runs. The Spring Boot plugin names the plain jar werkprobe-plain.jar; dist still collects it and the libraries, so the flat classpath on a managed webspace runs either main class. run-probe.sh --spring picks the new one. Squashed from branch spring-boot-jdbc-tc and pushed to main directly; the pull request was opened afterwards, not before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>