Upgrade testcontainers to 0.16 #3063
Conversation
|
The next release of testcontainers should fix the cargo-deny issues by pushing the serde-java-properties dependency behind a Cargo feature. |
Cargo.toml
Outdated
| @@ -98,7 +98,7 @@ signal-hook-tokio = "0.3.1" | |||
| sqlx = "0.7.4" | |||
| stopper = "0.2.7" | |||
| tempfile = "3.10.1" | |||
| testcontainers = "0.15.0" | |||
| testcontainers = { version = "0.16.3", features = ["blocking"] } | |||
There was a problem hiding this comment.
Is there a good reason not to use the AsyncRunner everywhere -- it looks like you already used it everywhere except for EphemeralDatabase? Dropping the use of SyncRunner would let us drop the blocking feature.
There was a problem hiding this comment.
No, I was thinking of doing that as a follow-up once everything was working
| @@ -57,8 +57,7 @@ impl EphemeralDatabase { | |||
| let shutdown_barrier = Arc::clone(&shutdown_barrier); | |||
| move || { | |||
| // Start an instance of Postgres running in a container. | |||
| let container_client = testcontainers::clients::Cli::default(); | |||
| let db_container = container_client.run(RunnableImage::from(Postgres::default())); | |||
| let db_container = RunnableImage::from(Postgres::default()).start(); | |||
There was a problem hiding this comment.
If the reason we're still using the sync interface in this one place is because of the use of a (synchronous) thread, I think this would be pretty easy to replace with an async task -- other than the testcontainers interface & the async channel (which are already async), we use a Barrier to communicate shutdown. This Barrier could pretty easily be replaced by another oneshot channel, for example, to allow us to async-ify all of the blocking operations.
|
Looks like |
Testcontainers-rs published a big refactor over the weekend, this PR updates to adapt to the API changes. The biggest changes are that testcontainer clients are no longer part of the API surface, and the library now takes care of lazily instantiating them, plus the non-async client now wraps the HTTP-based client in a new Tokio runtime, rather than shelling out to Docker's CLI. We have to switch to the async API in several places where we are already running inside a Tokio runtime.