testcontainers / testcontainers-dotnet

A library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions.

Home Page:https://dotnet.testcontainers.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Enhancement]: Upgrade to Azurite >= 3.28.0 and support in-memory persistence

Xzelsius opened this issue · comments

Problem

The current usage pattern of Azurite assumes that the caller is interested in persisting stored data beyond the lifetime of the node process. This certainly is useful for extended testing scenarios or where Azurite is actually used for production-like scenarios (perhaps a best-effort approach of free, on-prem Azure Storage). However, some Azurite use cases are more ephemeral in nature. For example, if you simply want to use Azurite for a single test run in a CI pipeline, you don't need the storage to persist beyond the lifetime of the node process.

Quote from: https://github.com/Azure/Azurite/blob/105a9cd217b881922016edb7a683ebea1ab3b28a/docs/designs/2023-10-in-memory-persistence.md

Depending on the amount and size of for example a blob there is an additional overhead on the test environment when Azurite has to write it to disk. In most scenarios, test containers won't survive more than one test run. So the overhead of writing to disk could be removed.

Solution

Upgrade to Azurite 3.28.0 or later and add support for the --inMemoryPersistence argument

Benefit

Using in-memory persistence may have a positive effect on overall performance of Azurite during tests, as it does not need to store stuff on disk.

Alternatives

Leave the current implementation as is

Would you like to help contributing this enhancement?

Yes

If this is being added, --extentMemoryLimit <size limit in MB> should also be supported.
And it should be discussed whether in-memory persistence is the default or opt-in.

Indeed, this sounds like a good and reasonable change to the module. Removing an existing default configuration is always a bit tricky with the current builder design (read-only configuration). This speaks for an opt-in approach (in addition, it reduces the chances of breaking existing configurations). Besides that, I do not really have an option regarding opt-in or opt-out.

So I would give it a try later today.
If I struggle to extend the current implementation I get back to you :)