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.