Azure Pipelines: "The current operating system is not capable of running this task": a Windows-only task on a Linux or macOS agent
Every task says in its task.json how the agent runs it: with Node, which works on Windows, Linux and macOS, or with a Windows-only handler such as PowerShell3. When a job on a Linux or macOS agent reaches a task that has only Windows handlers, the agent has nothing it can start and the step fails before the task does anything. Run that job on a Windows agent, or use a version or a task that has a Node handler (a Stack Overflow question on this message has been seen almost 10,000 times).
When this fails a pull request's build validation, the required build stays failed until a run on the right agent passes: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, and with Pro runs a failed build policy again once the pipeline is fixed. Get it on JetBrains Marketplace
What it looks like
##[error]The current operating system is not capable of running this task. That typically means the task was written for Windows only. For example, written for Windows Desktop PowerShell.- The step's log shows the task's name and version first (
Task : Azure file copy,Version : 6.282.2) and then this line; nothing of the task itself has run. The agent's source picks a handler for the step, and on Linux and macOS the PowerShell3, PowerShell, PowerShellExe and Process handlers are never offered (TaskManager.cs).
Is the task Windows-only? Read its task.json
- The
executionsection of a task'stask.jsonlists its handlers. OnlyPowerShell3(orPowerShell,Process) means Windows only; aNode,Node16,Node20_1orNode24entry means it also runs on Linux and macOS. Microsoft's built-in tasks are in the azure-pipelines-tasks repository; on a self-hosted agent, the tasks it downloaded are under its_work/_tasksfolder. - Built-in tasks that list only Windows handlers today include Azure file copy (
AzureFileCopy@5,@6), Visual Studio build (VSBuild@1), Azure PowerShell up to@3, Azure SQL Database deployment (SqlAzureDacpacDeployment@1), Windows machine file copy, PowerShell on target machines, Service Fabric deploy and the batch script task (BatchScript@1). - Microsoft's pages say so too: Azure file copy "works only when run on Windows agents" (AzureFileCopy@6), and Visual Studio build is supported only on Windows agents (VSBuild@1).
- A task from a Marketplace extension works the same way: its
task.jsonis in the extension, and an extension written in PowerShell runs only on Windows. Another extension may do the same job with Node; the accepted answer on a Stack Overflow question about a Terraform task points to two that run on all three systems.
Run the job on Windows
- On a Microsoft-hosted agent, set the job's pool to a Windows image:
pool: vmImage: windows-latestin YAML, or Agent Specificationwindows-latestin a classic pipeline. Only the job with the Windows-only task needs to move; the other jobs can stay onubuntu-latest. - In a self-hosted pool with agents of both kinds, send the job to a Windows agent with the demand
Agent.OS -equals Windows_NT(Demands).Agent.OSisLinuxorDarwinon the others. - Check that the pool is the one you meant. In a question about a self-hosted agent, the answer was to point the YAML at the pool of the Windows agent.
Or use a task that runs anywhere
- Azure file copy to Blob storage:
az storage blob upload-batch(orazcopy) in the Azure CLI task,AzureCLI@2, which has Node handlers; Microsoft's page for Azure file copy suggests the Azure CLI task for Linux agents. - Azure PowerShell:
AzurePowerShell@4and@5have a Node handler as well as PowerShell3, so on Linux and macOS they run your script withpwsh.@3and older do not. - Visual Studio build: an SDK-style project builds with
dotnet build(DotNetCoreCLI@2or a script). A project that needs Visual Studio's own build tools, such as a C++ project, needs a Windows agent. - A batch script:
script:orCmdLine@2runs a shell script on Linux and macOS and cmd on Windows.
Telling it apart
- On a Windows agent the same situation reads
A supported task execution handler was not found. The task does not carry an implementation that is compatible with your current operating system, with the system and architecture after it. The agent gives it, for example, for a task with only the older PowerShell or AzurePowerShell handlers on a 32-bit agent. - The job never starts and waits or fails with
No agent found in pool ... which satisfies the specified demands: a task's demand (msbuild,visualstudio,azureps) that no agent in a self-hosted pool has. See that page.
Azure DevOps pull requests in IntelliJ IDEA and Rider
Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and with Pro you run a failed or expired build policy again from there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.
Get it on JetBrains Marketplace
Azure DevOps and Azure Pipelines are trademarks of Microsoft Corporation; GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, GitHub, Inc. or JetBrains.
More: no zip where the deploy task looks · no agent in the pool meets the demands · an agent that stopped answering during the job · no Microsoft-hosted parallel job yet · 日本語