Fix for TwoPhaseFailedToStoreMetadataForCacheEntry error bucket influx.
When the CancellationToken is requested, we log the TwoPhaseFailedToStoreMetadataForCacheEntry error and return a null entry.
But we do not want CancellationToken related issues to go under this bucket. Also in the parent method we have a Contract which checks for the error to be logged if it receives a null entry. Handled this by adding an enum to include the three different states of the operation to store two-phase cache entry.
Related work items: #2231114
This complements !816459. A deadlock was caused by the method `EnsureLoadedAsync()` queuing tasks (by virtue of awaiting async methods) into a dedicated task scheduler that was asynchronously waiting for `EnsureLoadedAsync` itself. That PR solved the issue by ensuring this method does not await and just returning `Task`s, and this PR makes it tighter by switching it to a property, which will never allow awaits
Make provisions for shardset domains. This is a side car change to the changes being made in the CB repo
https://mseng.visualstudio.com/Domino/_git/CloudBuild/pullrequest/815932
The idea behind this change is to accommodate for arbitrary values that a domain id maybe. The data type of domain id sort of leaked through into BXL and CB. That is implementation detail and `DomainIdFactory.Create` is responsible for managing that translation and should be used instead.
With this change, I expect CB and BXL to be able to pass in arbitrary string values to drop service.
Automatic installation is becoming the default for the workflow, but we don't want to use it in our selfhost builds, where we intentionally want to run BuildXL from custom locations for testing and such
The constructor creates an object that will be immediately discarded - the compiler can't optimize this away:
| Method | Mean | Error | StdDev | Gen0 | Gen1 | Gen2 | Allocated |
|------- |----------:|----------:|----------:|----------:|----------:|---------:|----------:|
| Old | 17.564 ms | 0.1729 ms | 0.1444 ms | 1875.0000 | 1093.7500 | 343.7500 | 18.31 MB |
| New | 5.434 ms | 0.1077 ms | 0.2600 ms | 757.8125 | 750.0000 | - | 9.16 MB |
A deadlock can occur when the current context has all active threads running EnsureLoadedAsync which queues up an async task to that context.
To ensure this doesn't happen ensure we do not do any async/await in this method and ensure we return task result(s) that either are static or are from the singleton lazy initialization task.
This was subtly introduced with !797423
This should address #2229869 based on the dumps we have analyzed
In the crash we find that the version is a single digit number which is causing the Version.ParseVersion method within TryParse to fail. It expects a "." to be present within the version. Hence converting the version from say 11 to 11.0 to create a valid version for TryParse to parse.
Related work items: #2215963
Update nuget references so the whole closure is within the specified version ranges. After we get the new LKG we can turn off `doNotEnforceDependencyVersions: true`
Add a tool that validates the configuration to be deployed to AdoBuildConfig. This will be used to gate changes in that repository so that we always deploy configurations compatible with the installer.
Usage: `1ES.BuildToolsInstaller.Exe configcop --path <path-to-config-to-validate>`
Generally, output streams are handled in chunks to prevent them from reading everything into memory at once. But there was a check added back in commit 0167f82124 which violated this for sake of doing some checks for whether the output was truncated. This change reworks that handling to prevent it from calling ReadValueAsync() which reads in the entire stream.
I also changed ReadValueAsync to truncate rather than OOM as it is called in a number of places where we probably don't want to bother having elaborate chunking behavior.
Related work items: #2229870
We'd like to run some worker count experiments for Windows builds. We don't currently have a way to have CloudBuild do this, so a workaround is to utilize the engine's abtest flag with a mode that immediately releases a configurable number of workers.
This is wasteful since it will waste some machine time preparing a worker that will eventually get lost, but it is much easier to implement at this level. Moreover, this translates to ADO based distributed builds.
Nuget packages can specify group dependencies that are conditioned by a given target framework. E.g.:
```xml
<dependencies>
<group targetFramework="net6.0">
<dependency id="jQuery" version="1.10.2" />
<dependency id="WebActivatorEx" version="2.2.0" />
</group>
</dependencies>
```
The semantic of the condition is 'any framework compatible with net6.0 and the target framework' and not just net6.0. However, our nuget spec generation logic was adding this dependency **only** for net6.0. This was causing some dependent Nuget packages to be missing at deployment time. So far, we've been compensating for that manually adding the missing packages as explicit imports. But this is a risky practice since some packages might be required just at runtime and this might become evident only under particular code paths.
Modify the dependency generated logic to include all compatible frameworks wrt the specified framework dependency. This is a relatively safe change because at most we will be deploying *more* libraries than before. It should also allow us to clean up specs considerably after this reaches the LKG.