db9cad3928
This PR has 2 set of changes: 1. It creates a test that covers async copy on pin in way more details. It checks that the lifetime of the pin and async copies are not linked to each other and it also checks that the location is registered once the async copy is done. 2. It changes the behavior of `CancellableOperationContext.Dispose` method. This is actually the root cause of the cancellations we were seeing in async copies on pin. `CancellableOperationContext` effectively links a given context together with another cancellation token. The main use case for that is to have a special context that will notify about a shutdown cancellation. But in some cases, the call to `Dispose` method was cancelling a context as well. Here is the scenario: `ContentSessionBase.PinAsync` was creating a "linked" context and was passing it to `PinCoreAsync`. Because of the behavior I mentioned above, the token from the context was cancelled when the pin is done. This was causing the cancellation of the async operation before. Related work items: #1755629 |
||
---|---|---|
.config | ||
.vscode | ||
Documentation | ||
Examples | ||
Private | ||
Public | ||
Shared | ||
cg | ||
third_party | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
BuildCache.cmd | ||
BuildCacheDefault.json | ||
BuildCacheDefaultNetCore.json | ||
BuildCacheOverride.json | ||
CODEOWNERS | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
CreatePr.cmd | ||
LICENSE | ||
README.md | ||
RunCheckInTests-Test.cmd | ||
RunCheckInTests.cmd | ||
RunCheckInTestsWithPAT.ps1 | ||
SECURITY.md | ||
SlimBuildForMacTests.cmd | ||
buddy.cmd | ||
bxl.cmd | ||
bxl.sh | ||
bxlanalyzer.cmd | ||
clean.bat | ||
config.dsc | ||
config.microsoftInternal.dsc | ||
config.nuget.aspNetCore.dsc | ||
config.nuget.dotnetcore.dsc | ||
config.nuget.grpc.dsc | ||
config.nuget.vssdk.dsc | ||
domino.cmd | ||
drop.cmd | ||
dropout.cmd | ||
macos.mounts.dsc |
README.md
Microsoft Build Accelerator
Introduction
Build Accelerator, BuildXL for short, is a build engine originally developed for large internal teams at Microsoft, and owned by the Tools for Software Engineers team, part of the Microsoft One Engineering System internal engineering group. Internally at Microsoft, BuildXL runs 30,000+ builds per day on monorepo codebases up to a half-terabyte in size with a half-million process executions per build, using distribution to thousands of data center machines and petabytes of source code, package, and build output caching. Thousands of developers use BuildXL on their desktops for faster builds even on mega-sized codebases.
BuildXL accelerates multiple build languages, including:
- MSBuild (using new features under development in MSBuild 16 which will ship in future versions of Visual Studio 2019 and the .NET Core SDK)
- CMake (under development)
- Its own internal scripting language, DScript, an experimental TypeScript based format used as an intermediate language by a small number of teams inside Microsoft
BuildXL has a command-line interface. There are currently no plans to integrate it into Visual Studio. The project is open source in the spirit of transparency of our engineering system. You may find our technology useful if you face similar issues of scale. Note that BuildXL is not intended as a replacement for MSBuild or to indicate any future direction of build languages from Microsoft.
Documentation
The BuildXL documentation main page is here.
Examples and Demos
See the Examples/
folder for basic project examples. See the Demos page for information about various technical demos like using the process sandboxing code.
Building the Code
Build Status - Azure DevOps Pipelines
Command Line Build and Test
See the Developer Guide for instructions on compiling BuildXL.
Contributing
See CONTRIBUTING.