Pipelines Explorer

See every build and release pipeline across your organization, grouped by repo — and catch the classic pipelines you forgot to delete after moving to YAML.

A lightweight Azure DevOps extension that adds a Pipelines Explorer hub at both the organization and project level. It inventories every repository's build and release pipelines — YAML and classic alike — and flags the inconsistencies that creep in during a YAML migration.

Features

• Per-repository view — for every repo, see its YAML build pipeline(s), classic build pipeline(s), and the classic release pipeline(s) that consume it, in one place. No more clicking through Pipelines project by project.
• Duplicate / migration warnings — the headline feature. A repo that has a YAML build and a leftover classic build or release is flagged, so you can find and retire the stragglers. When a classic pipeline's name matches a YAML one, it's called out as a likely 1:1 duplicate.
• Drill into any pipeline — a side panel shows metadata, last-run status, triggers, and — for YAML pipelines in Azure Repos — an inline preview of the YAML file with its triggers, schedules, stages, and extends template parsed out. (YAML triggers live in the file, not the definition, so the file is read as the source of truth.)
• Organization-wide or per-project — the org hub enumerates every project; the project hub scopes to the one you're in. Filter by project, search by repo or pipeline name, and toggle "only repos with warnings."
• Tabs — By repository, YAML pipelines, Classic builds, Classic releases, and Warnings.
• Deep links — open any pipeline, release, or repo straight in Azure DevOps.
• Clean up classic leftovers — from a classic build pipeline's panel you can optionally clear its retention leases and "retain indefinitely" runs and then delete the pipeline; from a classic release pipeline's panel you can force-delete the release pipeline and all its releases. Guarded by a type-the-name-to-confirm step, acting only on the single pipeline you choose. (Requires the build/release write scopes and your own delete permission — see below.)

Who it's for

Teams part-way through (or long past) a classic-to-YAML migration who want a single, honest inventory of what's actually wired up — and where the dead classic pipelines and duplicates are hiding.

Requirements

• Read access to the projects, repositories, and pipelines you want to inventory. The extension uses your existing Azure DevOps session and shows only what you can already see.
• Full-fidelity repo metadata and inline YAML preview require the pipeline's code to live in Azure Repos Git. Pipelines hosted in GitHub or other external repos still appear (with their definition details and a deep link), but without inline preview.

Permissions and data handling

The extension requests vso.code and vso.project (read), plus vso.build_execute (build read and execute) and vso.release_manage (release read and manage). The two write scopes exist solely for the optional clean & delete actions — deleting a build or release pipeline (and clearing a build's retention leases) are write operations, and Azure DevOps offers no narrower scopes for them. Everything else the extension does is read-only.

Deletion is always explicit and self-service: it happens only when you open a pipeline, choose delete, and type its name to confirm — and it still respects your own Azure DevOps permissions (you need Delete build pipeline / Manage retention, or the corresponding release permission, or the request is refused). The extension runs entirely in your browser using your existing session. Nothing is stored, no data leaves your Azure DevOps tenant, and no telemetry is sent.

Admins: because this scope grants write/execute on Builds, updating from an earlier read-only version requires you to review and re-authorize the extension's permissions before it will load again.

Frequently asked questions

What counts as a "duplicate" warning? A repository that has at least one YAML build pipeline and at least one classic build pipeline (or a classic release pipeline consuming its artifacts). The classic one is usually a leftover from before the YAML migration. Matching names get an extra "likely 1:1 duplicate" note.

Why does it ask for build/release write permission? The only write actions are the optional clean & delete commands: on a classic build pipeline it clears retention leases and "retain indefinitely" runs then deletes it (vso.build_execute); on a classic release pipeline it force-deletes the release pipeline and its releases (vso.release_manage). Azure DevOps has no read-only way to delete either. If you never use delete, the extension only ever reads. Every deletion is gated behind a type-to-confirm dialog and your own delete permission, and acts on one pipeline at a time.

I deleted my classic pipeline and now I don't see the other pipeline at all — where did it go? You're almost certainly filtered to "Only repos with warnings." Deleting the leftover classic pipeline resolved that repo's duplicate warning, so the repo no longer matches the filter and drops out of the list — taking its (perfectly healthy) YAML pipeline along with it. Nothing was deleted by mistake. Clear the "Only repos with warnings" toggle, or open the YAML pipelines tab, and it reappears.

Why don't I see triggers on my YAML pipeline's definition? For YAML pipelines, triggers are usually defined inside the .yml file rather than on the pipeline definition. The details panel parses the file itself and shows the trigger, pr, and schedules it finds, labeled as coming from the YAML file.

How are classic release pipelines matched to a repo? By their artifacts — a Git artifact maps to its repository directly, and a Build artifact maps through the build pipeline it consumes. Releases whose artifacts can't be mapped to a repo are grouped separately so you can still see them.

Does it work on Azure DevOps Server (on-prem)? The manifest targets Microsoft.VisualStudio.Services, which covers both cloud Services and Server 2022+. Development and testing happen against Azure DevOps Services (cloud); on-prem is best-effort.

Is any of my data sent anywhere? No. The extension calls the standard Azure DevOps REST APIs from your browser with your own session. Nothing is persisted and no third-party services are contacted.

Support

• Bug reports and feature requests: github.com/edufur/azure-pipelines-explorer-support/issues
• License: Free to use (including commercially), but closed-source — it may not be resold, redistributed, or reverse-engineered. Full text is in the bundled LICENSE file (linked under this listing's resources).

Support the project ☕

If Pipelines Explorer saved your team time hunting down stale classic pipelines, consider leaving a tip. Tips fund the time spent maintaining it, fixing bugs, and building the next feature teams ask for.

(This is an independent project — not affiliated with Microsoft or my employer.)