Azure DevOps actions

Every Azure DevOps action

• Azure DevOps: Add Work Item CommentAdd a comment to a work item. Unlike creating or updating one, a comment is plain text on its own endpoint: no field map involved. Comments accept simple HTML for formatting.
• Azure DevOps: Cancel BuildCancel an in-flight build. Cancellation is a request, not an instruction: the build moves to "cancelling" and finishes tearing down, so its final result arrives shortly afterwards. This is a Build API action because the Pipelines API has no cancel verb at all.
• Azure DevOps: Comment on Pull RequestComment on a pull request. Azure DevOps models PR comments as threads, so a new comment starts a thread; give a Thread ID to reply inside an existing one instead.
• Azure DevOps: Complete Pull RequestComplete (merge) a pull request, with the usual options: squash, delete the source branch, resolve linked work items. Azure DevOps refuses to merge a PR that has moved since you last read it, so this action re-reads the PR first and echoes its latest commit back; no extra step needed.
• Azure DevOps: Create Pull RequestOpen a pull request. Branch names can be given plainly ("main"): the full ref Azure DevOps insists on is filled in for you. Reviewers are given as identity IDs; Work Item IDs link the PR to the work it delivers.
• Azure DevOps: Create ReleaseCreate a classic release from a release pipeline. Note this is classic Release Management, which Microsoft has steered new work away from in favour of multi-stage YAML pipelines: if your project deploys from a pipeline, use Run Pipeline instead.
• Azure DevOps: Create Work ItemCreate a work item (Bug, Task, User Story, …). Fields are given as an ordinary name/value map: "title", "assigned to", "priority" and the like, or full reference names such as System.AreaPath. The JSON-Patch document Azure DevOps actually requires is built for you.
• Azure DevOps: Delete Work ItemDelete a work item. By default it goes to the project's recycle bin and can be restored; turn on Destroy Permanently to erase it outright, which cannot be undone.
• Azure DevOps: Get BuildGet one build by ID, including its status, result, requester and source branch.
• Azure DevOps: Get Build LogFetch a build's logs as text: the payload to paste into a chat message when a build fails. Leave Log ID blank to concatenate every log for the build in order; set it to fetch just one. Very large logs are truncated and flagged rather than silently clipped.
• Azure DevOps: Get Pipeline ArtifactGet a named artifact from a pipeline run, with a time-limited download URL. Artifacts are how a pipeline hands its output to the rest of a flow. The URL is returned rather than the bytes: build artifacts are routinely gigabytes.
• Azure DevOps: Get Pipeline RunGet a pipeline run's state and result: the polling half of run, wait, report. State and Result are SEPARATE: a run is only finished when State is "completed", and until then Result reads "unknown", which does not mean it failed.
• Azure DevOps: Get ProjectGet one Azure DevOps project by name or ID, including its description, visibility and state. Turn on Include Capabilities to also return the process template and version-control type.
• Azure DevOps: Get Pull RequestGet one pull request, including its merge status, reviewers and the last source commit. Merge Status is what tells you whether it can actually be completed.
• Azure DevOps: Get RepositoryGet one Git repository by name or ID: its default branch, size, web URL and clone URLs.
• Azure DevOps: Get Work ItemGet a work item by ID. Expand pulls in relations, links or every field; Fields narrows the response to the reference names you list. The two cannot be combined: Azure DevOps rejects that pairing.
• Azure DevOps: Get Work Items (Batch)Fetch many work items by ID in one go: paste a list of IDs and get the full items back. Azure DevOps caps a batch at 200, so longer lists are split automatically. Fields and Expand cannot be combined.
• Azure DevOps: List BranchesList a repository's branches, with each one's latest commit. Filter narrows by name prefix: "release/" returns only the release branches.
• Azure DevOps: List BuildsList builds across a project, filterable by definition, status, result and branch. This is the classic Build API rather than the Pipelines API: deliberately: the Pipelines API can only list runs of ONE pipeline, so a cross-pipeline view is only available here.
• Azure DevOps: List CommitsList commits in a repository, filterable by branch, author, date range and file path. Useful for building release notes or spotting what landed since a given date.
• Azure DevOps: List Pipeline RunsList the recent runs of one pipeline, newest first: for "did today's build pass?" style flows. The service returns its own recent window and takes no paging parameters, so Limit trims the list on our side.
• Azure DevOps: List PipelinesList the pipelines in a project, returning each one's ID, name and folder. The IDs this returns are what Run Pipeline takes.
• Azure DevOps: List ProjectsList the projects in an Azure DevOps organisation. Every other action needs a project, so this is the natural first step: and the connection test: it validates the Organisation URL and the Personal Access Token without touching anything else.
• Azure DevOps: List Pull RequestsList pull requests in a repository, filterable by status, creator, reviewer and target branch. "PRs awaiting review" is the classic use: set Status to Active and give a Reviewer ID.
• Azure DevOps: List ReleasesList classic releases in a project. Note this is classic Release Management, which Microsoft has steered new work away from in favour of multi-stage YAML pipelines: if your project deploys from a pipeline, use List Pipeline Runs instead.
• Azure DevOps: List RepositoriesList the Git repositories in a project, with each one's ID, default branch and clone URLs.
• Azure DevOps: List TeamsList the teams in a project. Mostly useful for scoping a WIQL query to one team's backlog, or for resolving a team ID to feed another tool.
• Azure DevOps: List Work Item CommentsList the comments on a work item, newest last. Note these are the discussion comments, not the field-change history.
• Azure DevOps: List Work Item TypesList the work item types available in a project: Bug, Task, User Story and whatever else the project's process template defines. Worth checking before Create Work Item: process templates are customisable, so the familiar names are not guaranteed.
• Azure DevOps: Query Work Items (WIQL)Run a WIQL query and return the matching work items, fully populated. WIQL itself returns ONLY id references no matter what the SELECT clause lists, so this action hydrates them for you (in batches of 200): otherwise the results would be unusable in a flow. Cap your query with a WHERE clause: large result sets are expensive and are trimmed at 2000 items.
• Azure DevOps: Run PipelineQueue a pipeline run: the headline action, and the reason to wire Azure DevOps into a flow at all. Returns immediately with the run in progress; pair it with Get Pipeline Run to wait for the outcome. Variables can be given as plain name/value pairs.
• Azure DevOps: Update Pull RequestUpdate a pull request's title, description or target branch: and this is also how you abandon one (set Status to Abandoned) or bring it back (Active). Publishing a draft is Draft = off. To merge, use Complete Pull Request.
• Azure DevOps: Update Work ItemUpdate a work item's fields. Give an ordinary name/value map: "state", "assigned to", "priority", or full reference names; set a value to null to clear that field. The JSON-Patch document Azure DevOps requires is built for you.

Also in DevOps