microsoft/azure-pipelines-tasks: the built-in Azure Pipelines tasks, and how to write your own

What problem azure-pipelines-tasks actually solves

Azure Pipelines ships with a fixed catalogue of tasks: MSBuild, VSTest, Azure PowerShell, Azure CLI, Docker, artifact publishing, and so on. Each of those is a folder in this repository. The README describes the repo as containing "the tasks that are provided out-of-the-box with Azure Pipelines and Team Foundation Server", and states the intent plainly: to give "open examples on how we write tasks" so that others can write tasks of their own.

So the audience is narrow. If you are running pipelines, you consume these tasks through the service UI and never touch this code. If you are writing a custom task, or trying to understand why a built-in one behaves the way it does, this is the reference. The README is direct about when not to bother: for custom functionality in a build or release, "it is usually simpler to use the existing script running tasks such as the PowerShell or Bash tasks." Writing a new task is justified only when you need deeper integration or reuse across many build definitions.

That framing is honest and worth taking at face value. A task is more machinery than a shell script: a manifest, a compiled bundle, localization files, and packaging rules. The repository exists to make that machinery reproducible.

How a task is structured: tool runner, return codes, timeline records

The README gives the clearest description of the mechanism: tasks are "simply tool runners". They know how to invoke a tool such as MSBuild or VSTest in a first class way, handle return codes, decide how to treat stdout and stderr, and write timeline records based on expected output. They also receive credentials that let them write back to TFS or Azure Pipelines.

That list is the real contract. A task is not just a command wrapper; it is responsible for translating a tool's exit status and console output into the pipeline's own model of success, failure and warnings. The timeline records are what you see in the log view, and they come from the task code, not from the agent.

The repository layout reflects this. Tasks live under Tasks/, with shared code in common-npm-packages/ and generated output in _generated/. Build logic sits in make.js, build-parallel.js, make-util.js and the build-scripts/ directory, with CI definitions in .azure-pipelines/ and ci/. Tests are split between Tests/ and Tests-Legacy/, and there is a separate BuildConfigGen/ directory. The top-level entries Compress-Tasks.ps1 and Expand-Tasks.ps1 point at how packaged tasks are compressed and unpacked for distribution.

Installing the build tooling and building a task

There is nothing to install for pipeline users. The README points to the continuous integration and deployment documentation at aka.ms/tfbuild for using tasks, and to the TFS Cross Platform Command Line utility for uploading custom tasks to Azure Pipelines. To work on the source itself you clone the repository and use the npm scripts defined in package.json, which all delegate to make.js.

Install dependencies first. The repository uses pnpm, and package.json declares a pnpm workspace, so the workspace-aware install is the one that matches the checked-in configuration:

pnpm install

Then build. The build script is a thin wrapper around make.js, and a parallel variant exists for machines with more cores:

node make.js build
node build-parallel.js build

The test entry points follow the same pattern. Note that legacy tests are a separate script rather than part of the default test run:

node make.js test
node make.js testLegacy

Packaging is a distinct step, which matters if you intend to upload the result rather than just compile it:

node make.js package

After a successful build, expect task output under the generated directory rather than in the task source folder. The repository does not document a rollback procedure for a bad package, so keep the previous artifact if you are replacing an uploaded task version.

Deprecation is the constraint that will bite you first

The most consequential operational fact in this repository is not in the README body but in DEPRECATION.md, which the README links twice. Deprecated tasks "will display a warning banner when used in pipelines, and will be removed after a 90-day notice period." That is a hard deadline, not a suggestion.

The stated reasons for deprecation are instructive about where the risk sits. Retired Azure services, security improvements such as newer authentication methods like Workload Identity Federation, outdated dependencies such as older versions of AzCopy or PowerShell modules, and the existence of better task versions. Three of those four are outside the control of anyone running a pipeline. If your pipeline pins an old task version because it works, the service underneath it can still be retired.

The practical consequence for anyone modelling a custom task on a built-in one: check DEPRECATION.md before you copy a pattern. A task that still builds cleanly may already carry a removal date. The README does not state how deprecation interacts with self-hosted agents that have cached task versions, and that gap is worth knowing about if your agents are long-lived.

Where this repository is the wrong tool

If you want to run a command in a pipeline, this repository is the long way round. The README says so itself: use the PowerShell or Bash tasks. Building and shipping a custom task means maintaining TypeScript, a task manifest, localization files and a packaging step, then uploading through the TFS Cross Platform Command Line utility or bundling the task into an Azure DevOps extension. That is a real maintenance surface for something a script task can often do in a few lines.

The second case is more awkward. This is Microsoft's own task source, not a community SDK with a stability promise. The package.json name is "Agent.Tasks" and the version is 0.6.0, which tells you the versioning is internal to the build rather than a published interface. Nothing in the README describes a supported consumption path for third parties beyond reading the code as an example. If you need a stable API to build against, this is not it.

A third case: if you are debugging a pipeline failure and the task is not deprecated and not custom, the answer is usually in the service documentation rather than here. Reading task source is a last resort, and the README offers no guidance on mapping a task name in the UI to a folder in Tasks/.

How this differs from writing an Azure DevOps extension

The README presents two distribution routes, and they are genuinely different in approach. Uploading a task with the TFS Cross Platform Command Line utility puts the task into your account or server directly. Packaging the task inside an Azure DevOps extension, which the README links a tutorial for, produces a distributable unit that can be installed across organisations and published to the marketplace.

The difference is not just packaging. An extension carries its own contribution manifest, versioning and installation lifecycle, and installing it is an action a user takes rather than a task you upload once. For a single team's internal task, the CLI route is less machinery. For something you intend to share or version independently of your pipelines, the extension route is the one that matches. The README does not compare the two beyond pointing at each, so the choice is left to you, but the maintenance burden differs sharply: an extension you publish becomes something you support.

Maintenance, licence and what to check before you commit

The repository is not archived. The last push was on 2026-09-23, and the release tags are close together: v279 on 2026-09-01, v278 on 2026-08-13, v277 on 2026-07-20. That cadence is consistent with a codebase that changes often, which cuts both ways. You get current task definitions, and you also inherit a moving target if you fork a task as your starting point.

The licence is MIT, declared in package.json and present as LICENSE.txt at the repository root. MIT is permissive, so reuse in a commercial internal task is not the obstacle. The thing to watch is not the repository licence but the licences of what a task invokes: the README's own deprecation list mentions older AzCopy versions and PowerShell modules, and those dependencies carry their own terms. There is also a generate-third-party-notice.js script in the root, which indicates the project tracks third-party notices as part of its build. That is not legal advice; read the notices your own distribution requires.

Upgrade cost is the harder question. Because tasks are versioned and shipped through the service, a task you depend on can be deprecated on the 90-day schedule described in DEPRECATION.md without any action on your part. Budget for that review, not for a dependency bump.

Editorial conclusion

Adopt this repository if you maintain custom Azure Pipelines tasks, need to read the source of a built-in task to explain its behaviour, or want the reference implementation of the task SDK patterns. Do not adopt it as an application dependency; there is no runtime library to install and no supported npm entry point for consumers. Before writing anything, check DEPRECATION.md for tasks already scheduled for removal and confirm the task you plan to model your work on has not been deprecated, then run the build for a single task rather than the whole tree.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/azure-pipelines-tasks on GitHub
3. Project website
4. README
5. Releases