Because Elasticsearch took away our ability to use Elasticsearch in embedded mode for tests (a really convenient feature, it’s just a shame that Elastic don’t care about developer experience anymore), we have experimented with various ways to automatically start a real cluster before tests, tearing it down after tests.
Initially, we did it somewhat like this:
val startEsCluster by tasks.registering { ... }
val stopEsCluster by tasks.registering { ... }
tasks.test {
dependsOn(startEsCluster)
finalizedBy(stopEsCluster)
}
If multiple tests ran, though, startEsCluster only ran once, so we eventually changed this to:
fun startEsCluster() { ... }
fun stopEsCluster() { ... }
tasks.test {
doFirst { startEsCluster() }
doLast { stopEsCluster() }
}
The remaining issue is that two tests which do this could be run at the same time - the first test which finishes will stop the cluster and break the other tests. There’s a third integration test suite being written which will do the same, so the odds of this happening are about to increase.
So we’re looking for a cleaner way to do this.
For CI, we could potentially spin it up from Jenkins, but that doesn’t help normal devs who expect to be able to run the tests locally.
So I’m wondering if there is some way to have a shared build resource which is started on first usage and shut down only on last usage.
I considered just spinning it up once and shutting it down at JVM shutdown, but when running inside the daemon, that effectively means it never shuts down. We do want it to shut down so that people have a decent chance of being able to run the clean task.
This is vaguely similar to the use case of starting/stopping a database, which might be a fairly common use case in some applications, so I figure someone has some idea of how this could work?
