6bc39a6bd7
* Split x64/arm64 builds into parallel pipeline stages Restructure the CI/CD pipeline to build x64 and arm64 in parallel instead of sequentially, reducing end-to-end build time. Pipeline shapes: - PR: build_x64 ∥ build_arm64 → test (uses installer.msix directly) - Nightly: build_x64 ∥ build_arm64 → package → test (dev-cert bundle) - Release: build_x64 ∥ build_arm64 → package → test (ESRP-signed bundle) Key changes: - Extract shared build-job.yml template parameterized by platform - Add package-stage.yml that creates msixbundle from both platform artifacts, ESRP-signs for release, dev-cert signs for nightly - PR tests run immediately after x64 build using installer.msix (no package stage, no bundle needed) - Release/nightly tests wait for the package stage and test the real signed bundle that gets published - CloudTest configs are parameterized: release tests pull the bundle from the [package] artifact, PR tests use installer.msix from [drop] - arm64 + formatting checks always run in parallel with x64 but don't block the PR test gate - CodeQL runs in the arm64 stage (off the critical path) - flight-stage and nuget-stage updated for new stage names * formatting * Remove redundant runtime conditions on release-only tasks These tasks are already wrapped in compile-time conditionals which prevent them from being added to the pipeline definition for non-release builds. The runtime condition checks can never evaluate to false at that point, so they are pure noise. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review feedback from OneBlue - Remove wslcsdk NuGet staging (wslc is not in master) - Always include [package] provider in TestMap.xml.in instead of conditionally injecting via PACKAGE_PROVIDER_BLOCK cmake variable. PR builds simply use [drop] as TEST_PACKAGE_PROVIDER; the [package] provider exists but is unused. - Add BUNDLE_ONLY cmake option so the package pipeline stage reuses cmake's existing bundle target instead of forking makeappx logic. This locks the SDK version via cmake (CMAKE_SYSTEM_VERSION) and keeps bundle creation logic in one place (msixinstaller/CMakeLists.txt). The pipeline now copies msix files to expected paths, runs a fast cmake configure with -DBUNDLE_ONLY=TRUE, and builds the bundle target. - Remove dead NuGet binary restore step in package stage. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address PR review feedback - Fix PACKAGE_VERSION regex: escape dots so only A.B.C.D is accepted - Consolidate CMake defaults (build type, config types, output dir) before BUNDLE_ONLY block to avoid duplication - Nightly tests now use the full bundle from the package stage instead of installer.msix (new INCLUDE_PACKAGE_STAGE cmake variable) - Package stage reuses version output from build stage instead of recomputing it Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Ben Hillis <benhill@ntdev.microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Welcome to the Windows Subsystem for Linux (WSL) repository
Learn more about WSL | Downloads & Release notes | Contributing to WSL
About
Windows Subsystem for Linux (WSL) is a powerful way for you to run your Linux command-line tools, utilities and applications, all unmodified and directly on Windows without the overhead of a traditional virtual machine or dual boot setup.
You can install WSL right away by running this command inside of your Windows command line:
wsl --install
You can learn more about best practices for setup, overviews of WSL and more at our WSL documentation page.
Related repositories
WSL also has related open source repositories:
- microsoft/WSL2-Linux-Kernel - The Linux kernel shipped with WSL
- microsoft/WSLg - Support for Linux GUI apps in WSL
- microsoftdocs/wsl - WSL documentation at aka.ms/wsldocs
Contributing
This project welcomes contributions of all types, including coding features / bug fixes, documentation fixes, design proposals and more.
We ask that before you start working on a contribution, please read our Contributor's Guide.
For guidance on developing for WSL, please read the developer docs for instructions on how to build WSL from source and details on its architecture.
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct
Trademarks
This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party’s policies.
Privacy and telemetry
The application logs basic diagnostic data (telemetry). For more information on privacy and what we collect, see our data and privacy documentation.
The software may collect information about you and your use of the software and send it to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may turn off the telemetry as described in the repository. There are also some features in the software that may enable you and Microsoft to collect data from users of your applications. If you use these features, you must comply with applicable law, including providing appropriate notices to users of your applications together with a copy of Microsoft’s privacy statement. Our privacy statement is located at https://go.microsoft.com/fwlink/?LinkID=824704. You can learn more about data collection and use in the help documentation and our privacy statement. Your use of the software operates as your consent to these practices.