/cc @gsmet (hibernate-orm)

Yes, it's a trick in the source itself :)

Originally, the JDBC Extension queried the JDBC URL value at build time to either start or skip the DevService. In cases where the URL was an expansion, this would fail if the expansion is not available at build time. In the original issue, the JDBC URL was set as an expansion in Vault, only available at runtime (see what I mean that we shouldn't be querying runtime configuration at build time? :))

So I've changed that to just query for the name to be available, since we don't care about the value at all when we have to determine if we launch the DevService. To simulate the original issue, the source only sets quarkus.datasource.jdbc.url at build time, and then gives no value at runtime:

So in this case, you get a value at build time, which disables the DevService, and then when runtime starts, there is no value, which causes the message saying that the URL is not set.

Testing for this particular situation when using DevServices is mutually exclusive. We can either remove the config source and trust that our code is not querying for the actual config value (by always using ConfigUtils#isPropertyPresent or ConfigUtils#isAnyPropertyPresent), or we need the test not to use DevServices.

Originally, the JDBC Extension queried the JDBC URL value at build time to either start or skip the DevService. In cases where the URL was an expansion, this would fail if the expansion is not available at build time. In the original issue, the JDBC URL was set as an expansion in Vault, only available at runtime (see what I mean that we shouldn't be querying runtime configuration at build time? :))

So I've changed that to just query for the name to be available, since we don't care about the value at all when we have to determine if we launch the DevService. To simulate the original issue, the source only sets quarkus.datasource.jdbc.url at build time, and then gives no value at runtime:

Thank you for the explanation! So this would be a correct refactoring of the original test? Without this PR, that is. From

        if (isBuildTime) {
            return "${postgres.url}";
        }

        return super.getValue(propertyName);

to

        if (isBuildTime) {
            return "${arbitrary.unavailable.property}";
        }

        return super.getValue(propertyName);

Yes, it doesn't really matter what the expression configuration name is. We just want to ensure that the expression resolution is not available at build time and that we don't try to expand it, as that would cause an error.

Yes, it doesn't really matter what the expression configuration name is. We just want to ensure that the expression resolution is not available at build time and that we don't try to expand it, as that would cause an error.

Got it, thanks! I'll switch the property name to make it more clear it's not supposed to work. Since the other property was also used in the application.properties I thought it was supposed to be resolvable.

I've reworked the tests and I have something that passes, and I think it still exercises the same things, but I'd value a check from @radcortez. What I've done is use dev services for most of the tests in that project, and added a new test which uses a resource lifecycle manager to start postgres. I also tried @BeforeAll but of course that was way too late, and quarkus failed to start before the setup code even ran. I believe at build time the config from the resource lifecycle manager isn't present and the config source gets asked (which disables dev services), but then at runtime the resource manager operates normally. I can see in Podman Desktop a dev service doesn't get started if I run just the new test in isolation, and I can see from printlns that the config source is being invoked at build time.

Excellent!

I've address your review comments (thanks!). I think I've got something valid on the readme? I also noticed a similar issue on one of the reactive readmes so I've updated it as well. I didn't squash so you could see just those changes.

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 3bb7ab3.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.