Unsupported file format exception when providing MICRONAUT_CONFIG_FILES

[svetob]

Expected Behavior

Should be able to supply MICRONAUT_CONFIG_FILES env var to tests without impacting behaviour of internalStartTestResourcesService or causing an error.

Actual Behaviour

When supplying MICRONAUT_CONFIG_FILES environment variable, I get the following exception in the internalStartTestResourcesService build job, this causes the test build to hang indefinetely:

12:02:38.343 [ForkJoinPool.commonPool-worker-6] INFO  i.m.t.e.TestResourcesResolverLoader - Loaded 2 test resources resolvers: io.micronaut.testresources.mysql.MySQLTestResourceProvider, io.micronaut.testresources.testcontainers.GenericTestContainerProvider
12:02:38.349 [main] ERROR io.micronaut.runtime.Micronaut - Error starting Micronaut server: Unsupported properties file format while reading local-secrets.yml from src/test/resources/local-secrets.yml
io.micronaut.context.exceptions.ConfigurationException: Unsupported properties file format while reading local-secrets.yml from src/test/resources/local-secrets.yml
	at io.micronaut.context.env.DefaultEnvironment.lambda$readPropertySourceListFromFiles$6(DefaultEnvironment.java:488)
	at java.base/java.util.Optional.ifPresent(Optional.java:178)
	at io.micronaut.context.env.DefaultEnvironment.readPropertySourceListFromFiles(DefaultEnvironment.java:470)
	at io.micronaut.context.env.DefaultEnvironment.readPropertySources(DefaultEnvironment.java:416)
	at io.micronaut.context.env.DefaultEnvironment.start(DefaultEnvironment.java:270)

Steps To Reproduce

1. Create tests using test-resources
2. Supply environment variable MICRONAUT_CONFIG_FILES
3. Start tests

Environment Information

No response

Example Application

No response

Version

3.6.2

[melix]

Thanks for the bug report. It's an "interesting" side effect of the test resources service being a Micronaut application itself... Let me think about it.

[melix]

I have a solution to this problem which would require a new test resources release, but only for Micronaut 3.7+.

Since you are using Gradle, there is an alternative to this. You have the problem because you are running something like:

MICRONAUT_CONFIG_FILES=my-config.yml ./gradlew test

which exports the MICRONAUT_CONFIG_FILES globally. Instead, as a workaroud, you could alter the build script so that only the test task sees this environment variable. Something like this:

tasks.withType(Test).configureEach {
    def overrideEnv = System.getenv("CI_MICRONAUT_CONFIG_FILES")
    if (overrideEnv != null) {
        inputs.property("MICRONAUT_CONFIG_FILES", overrideEnv)
        environment.put("MICRONAUT_CONFIG_FILES", overrideEnv)
    }
}

Then on CI, instead of setting MICRONAUT_CONFIG_FILES you would set CI_MICRONAUT_CONFIG_FILES.

[svetob]

Thanks, that workaround did the trick! Thanks for the help.

We now have a different issue, but not sure if I should create an issue for it or if it's just a config issue. It seems the mysql container that the plugin starts is always uses the database name 'test', however our Liquibase migrations sometimes use the expected db name 'verification' causing the migrations to fail due to that DB not existing. How can I change the default DB name from 'test' to something else for Mysql? It seems it might involve changing the JDBC URL from jdbc:mysql://localhost:1234/test to end with another DB name than test, but not sure how to do that.

[svetob]

These docs suggest setting datasources.*.db-name https://micronaut-projects.github.io/micronaut-test-resources/latest/guide/

However, with this fix, test-resources does not see the src/test/resources/local.properties file where I assume this config should be applied.