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.
By microsoft · 2,863 installs
npx skills add microsoft/vscode --skill azure-pipelines
Source repository · Upstream listing
Validating Azure Pipeline Changes
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.
Prerequisites
1. Check if Azure CLI is installed :
If not installed, install it:
2. Check if the DevOps extension is installed :
If not installed, add it:
3. Authenticate :
VS Code Main Build
The main VS Code build pipeline:
Organization : monacotools
Project : Monaco
Definition ID : 111
URL : https://dev.azure.com/monacotools/Monaco/ build?definitionId=111
VS Code Insider Scheduled Builds
Two Insider builds run automatically on a scheduled basis:
Morning build : ~7:00 AM CET
Evening build : ~7:00 PM CET
These scheduled builds use the same pipeline definition ( 111 ) but run on the main branch to produce Insider releases.
Queueing a Build
Use the [queue command](./azure pipeline.ts) 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:
Script Options
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
Product Build Queue Parameters ( 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:
Checking Build Status
Use the [status command](./azure pipeline.ts) to monitor a running build:
Script Options
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
Cancelling a Build
Use the [cancel command](./azure pipeline.ts) to stop a running build:
Script Options
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
Testing Pipeline Changes
When the user asks to test changes in an Azure Pipelines build , follow this workflow:
1. Queue a new build on the current branch
2. Poll for completion by periodically checking the build status until it finishes
Polling for Build Completion
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 watch flag polls every 30 seconds by default. Use watch 60 for a 60 second interval to reduce API calls.
Common Workflows
1. Quick Pipeline Validation
2. Investigate a Build
3. Test with Modified Parameters
4. Cancel a Running Build
5. Iterate on Pipeline Changes
When iterating on pipeline YAML changes, always cancel obsolete builds before queueing new ones:
Troubleshooting
Authentication Issues
Extension Not Found
Rate Limiting
If you hit rate limits, add delays between API calls or use watch with a longer interval.