Use Cosmos emulator instead of Azure instance #19263
Conversation
roji
commented
Dec 10, 2019
roji
commented
- Windows job downloads and sets up a local Cosmos emulator, and tests against it.
- Linux job no longer runs tests against our Azure instance.
* Windows job downloads and sets up a local Cosmos emulator, and tests against it. * Linux job no longer runs tests against our Azure instance.
| condition: ne(variables.CACHE_RESTORED, 'true') | ||
| displayName: Download CosmosDB Emulator | ||
| - powershell: msiexec /i cosmosdb-emulator-cache-dir\cosmosdb-emulator.msi /qn /quiet /norestart /log install.log | ||
| displayName: Install CosmosDB Emulator |
There was a problem hiding this comment.
- Can the emulator be
xcopyinstalled? Making permanent changes to the AzDO agents is not recommended.- If yes, probably best to ask .NET Core Eng add the ZIP to https://netcorenativeassets.blob.core.windows.net
- Why repeat the installation if the MSI has already been installed? I suggest checking for the
Azure Cosmos DB Emulatorfolder before doing this.
There was a problem hiding this comment.
Hey @dougbu, thanks for taking a look. I'm a total newcomer to our build system so there's likely to be some silliness here.
So do I understand correctly that an MSI installation would persist on the agent, i.e. that state is carried over from one build to the next? Because I was operating with the assumption that the build runs in a VM which is later reset, like the way things work on a normal non-hosted Azure Pipelines build.
I don't think there's a simple xcopy install option for the Cosmos Emulator (here are the docs). They do provide a docker image which I've tried to set up as a service container, but apparently our agents don't have the right version of Windows to support that. The current MSI-based installation also seems like it's much faster because we can cache.
However, if agents don't reset between builds, then is it possible simply have this MSI installed in all our agents once (or included in our image), rather than do it in our script every single time? Aside from having to mess around with caches, it seems like it would be easier to manage upgrades as well (we'd ask for a manual upgrade every now and then, it should really happen pretty rarely).
Thanks for your help and insights on this!
There was a problem hiding this comment.
There was a problem hiding this comment.
@roji the BYOC queues work differently from the hosted AzDO queues.
@MattGal what's the process to request the addition of the Cosmos Emulator to the BuildPool.Windows.10.Amd64.VS2017 and BuildPool.Windows.10.Amd64.VS2017.Open queues? Is this doable in a reasonable timeframe?
Create an issue in dotnet/core-eng and we'll discuss in triage. At this point your timeframe is "next year" as at best we'll only have one more rollout before EOY.
There was a problem hiding this comment.
@ajcvickers @roji is "next year" soon enough?
There was a problem hiding this comment.
I'll start a thread about this offline.
|
Closing in favor of #19309 |
