npx skills add ...
npx skills add microsoft/vscode --skill azure-pipelines
npx skills add microsoft/vscode --skill azure-pipelines
Use when validating Azure DevOps pipeline changes for the VS Code build. Covers queueing builds, checking build status, viewing logs, and iterating on pipeline YAML changes without waiting for full CI runs.
When modifying Azure DevOps pipeline files (YAML files in build/azure-pipelines/), you can validate changes locally using the Azure CLI before committing. This avoids the slow feedback loop of pushing changes, waiting for CI, and checking results.
Check if Azure CLI is installed:
If not installed, install it:
Check if the DevOps extension is installed:
If not installed, add it:
Authenticate:
The main VS Code build pipeline:
monacotoolsMonaco111Two Insider builds run automatically on a scheduled basis:
These scheduled builds use the same pipeline definition (111) but run on the main branch to produce Insider releases.
Use the queue command to queue a validation build:
Important: Before queueing a new build, cancel any previous builds on the same branch that you no longer need. This frees up build agents and reduces resource waste:
| Option | Description |
|---|---|
--branch <name> | Source branch to build (default: current git branch) |
--definition <id> | Pipeline definition ID (default: 111) |
--parameter <entry> | Pipeline parameter in KEY=value format (repeatable); use this when the value contains spaces |
--parameters <list> | Space-separated parameters in KEY=value KEY2=value2 format; values must not contain spaces |
--dry-run | Print the command without executing |
build/azure-pipelines/product-build.yml)| Name | Type | Default | Allowed Values | Description |
|---|---|---|---|---|
VSCODE_QUALITY | string | insider | exploration, insider, stable | Build quality channel |
VSCODE_BUILD_TYPE | string | Product Build | Product, CI | Build mode for Product vs CI |
NPM_REGISTRY | string | https://pkgs.dev.azure.com/monacotools/Monaco/_packaging/vscode/npm/registry/ | any URL | Custom npm registry |
CARGO_REGISTRY | string | sparse+https://pkgs.dev.azure.com/monacotools/Monaco/_packaging/vscode/Cargo/index/ | any URL | Custom Cargo registry |
VSCODE_BUILD_WIN32 | boolean | true | true, false | Build Windows x64 |
VSCODE_BUILD_WIN32_ARM64 | boolean | true | true, false | Build Windows arm64 |
VSCODE_BUILD_LINUX | boolean | true | true, false | Build Linux x64 |
VSCODE_BUILD_LINUX_SNAP | boolean | true | true, false | Build Linux x64 Snap |
VSCODE_BUILD_LINUX_ARM64 | boolean | true | true, false | Build Linux arm64 |
VSCODE_BUILD_LINUX_ARMHF | boolean | true | true, false | Build Linux armhf |
VSCODE_BUILD_ALPINE | boolean | true | true, false | Build Alpine x64 |
VSCODE_BUILD_ALPINE_ARM64 | boolean | true | true, false | Build Alpine arm64 |
VSCODE_BUILD_MACOS | boolean | true | true, false | Build macOS x64 |
VSCODE_BUILD_MACOS_ARM64 | boolean | true | true, false | Build macOS arm64 |
VSCODE_BUILD_MACOS_UNIVERSAL | boolean | true | true, false | Build macOS universal (requires both macOS arches) |
VSCODE_BUILD_WEB | boolean | true | true, false | Build Web artifacts |
VSCODE_PUBLISH | boolean | true | true, false | Publish to builds.code.visualstudio.com |
VSCODE_RELEASE | boolean | false | true, false | Trigger release flow if successful |
VSCODE_STEP_ON_IT | boolean | false | true, false | Skip tests |
VSCODE_USE_LEGACY_OSS_NOTICE | boolean | false | true, false | Keep the legacy mixin ThirdPartyNotices.txt instead of the Component Governance notice |
Example: run a quick CI-oriented validation with minimal publish/release side effects:
Use the status command to monitor a running build:
| Option | Description |
|---|---|
--build-id <id> | Specific build ID (default: most recent on current branch) |
--branch <name> | Filter builds by branch name (shows last 20 builds for branch) |
--reason <reason> | Filter builds by reason: manual, individualCI, batchedCI, schedule, pullRequest |
--definition <id> | Pipeline definition ID (default: 111) |
--watch [seconds] | Continuously poll status until build completes (default: 30s) |
--download-log <id> | Download a specific log to /tmp |
--download-artifact <name> | Download artifact to /tmp |
--json | Output raw JSON for programmatic consumption |
Use the cancel command to stop a running build:
| Option | Description |
|---|---|
--build-id <id> | Build ID to cancel (required) |
--definition <id> | Pipeline definition ID (default: 111) |
--dry-run | Print what would be cancelled without executing |
When the user asks to test changes in an Azure Pipelines build, follow this workflow:
Use a shell loop with sleep to poll the build status. The sleep command works on all major operating systems:
Alternatively, use the built-in --watch flag which handles polling automatically:
Note: The
--watchflag polls every 30 seconds by default. Use--watch 60for a 60-second interval to reduce API calls.
When iterating on pipeline YAML changes, always cancel obsolete builds before queueing new ones:
If you hit rate limits, add delays between API calls or use --watch with a longer interval._