What is the lifetime of a CosmosDB emulator instance started via Start-CosmosDBEmulator cmdlet during ci

[tristanbarcelon]

Inside one of our Azure Devops build definitions, we have the following steps:

1. dotnet restore solution file
2. visual studio build solution file (includes unit test projects)
3. start cosmos db emulator with a specific datapath location using the Start-CosmosDBEmulator powershell cmdlet that came with Azure CosmosDB emulator without rate limiting and a default partition count of 100
4. transform app.config file(s) of unit test dlls In this step, we are appending Agent.Id to the databasename that will be used when connecting to CosmosDB emulator to ensure that multiple builds on the same build server will not affect each other. For example, if databasename in app.config is equal to test_assemblies then it will become test_assemblies12. The test fixture takes care of creating the database at startup and destroying it upon teardown.
5. execute visual studio test against unit test projects

We use on-premise bare metal build servers and have installed Azure CosmosDB emulator on it. There are 12-16 instances of Azure Devops build agent running per server and this is by design to minimize the number of software installations we have to maintain.

Expected behavior

Once an instance of Azure CosmosDB emulator is running, we expect it stay up across multiple builds jobs on the same build server.

Thus, if build 12345 job is queued first and starts the emulator, another build 12346 that is queued should be able to find it in a running state instead of in a stopped state.

Likewise, I expected the build which started the emulator instance to finish with the emulator still running and available for subsequent builds.

Actual behavior

From time to time, the unit test dlls will fail connecting to the local cosmosdb emulator. Sometimes, it will fail near the end of the tests by exhibiting slow operations. The build definition is not checking the emulator status in step 3. Instead, it is just calling Start-CosmosDBEmulator.

Is there another way to run cosmosdb in a persistent way similar to a windows service? There is an Azure Devops task for running CosmosDB emulator as a container and we may try that but the question remains the same. Can we keep the container running consistently and have it be accessible by multiple builds/unit tests concurrently? I prefer not to use that task because I'd need to bind a host folder and install certificates each time the container starts.

[KalyanChanumolu-MSFT]

Closing this issue as it is a duplicate of #33048