Add an Azure Pipelines ecosystem

[JamieMagee]

What are you trying to accomplish?

Updates task: steps in Azure Pipelines YAML, so a pipeline on Maven@3 gets offered Maven@4.

Versions come from microsoft/azure-pipelines-tasks at its latest release tag. The Azure DevOps API for this needs credentials for a specific organization, which Dependabot doesn't have.

Anything you want to highlight for special attention from reviewers?

Precision is the bit worth reviewing. Pipelines pin the major and the agent picks up minors itself. Maven's newest release is 4.276.0, so comparing whole versions would treat Maven@4 as stale and open a no-op PR. Candidates get truncated to the pinned precision first. GoTool@0.3.1 still updates in full.

Directory names aren't authoritative. ANTV1 declares "name": "Ant", so task.json decides the match.

One shared file changed: azure_pipelines joins PACKAGE_MANAGERS_WITH_RELIABLE_DIRECTORIES, otherwise the commits finder tries compare/3...4 against a repo whose tags are sprint numbers.

Marketplace tasks, GUID references and deprecated majors resolve to nothing on purpose.

How will you know you've accomplished your goal?

93 unit examples, plus 364 in common for the shared change. Rubocop and srb tc clean.

Dry run on microsoft/SDCM bumps NuGetToolInstaller@0 to @1 and correctly no-ops the other four, in 13 requests. DigitalRuby/ExchangeSharp bumps DownloadBuildArtifacts@0 and GitHubRelease@0. Cooldown holds a bump at 10,000 days and lets it through at 30.

Against live data: NodeTool@0 (deprecated) and SonarQubePrepare@7 (Marketplace) are left alone, Ant@1 resolves via ANTV1, GoTool@0.3.1 goes to 0.275.0, Docker@1 to 2.

Checklist

• I have run the complete test suite to ensure all tests and linters pass. (azure_pipelines specs, rubocop, srb tc, and the common specs covering the one shared file. CI covers the rest.)
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[Copilot]

Review details

Comments suppressed due to low confidence (2)

azure_pipelines/lib/dependabot/azure_pipelines/package/package_details_fetcher.rb:237

• The non-404 fallback is still reachable for a malformed 200 response: parse returns nil (or tag_name can be absent), and this expression then selects master. That recreates the unreleased-version risk this status handling is intended to prevent. Treat an invalid successful response as an error; only the explicit 404 branch should return DEFAULT_REF.

          parsed = parse(response.body)
          tag = parsed.is_a?(Hash) ? parsed["tag_name"] : nil

          tag.is_a?(String) && !tag.empty? ? tag : DEFAULT_REF

azure_pipelines/lib/dependabot/azure_pipelines/file_fetcher.rb:137

• MAX_CANDIDATES is not enforced while scanning one directory. If a directory contains more than 200 YAML files, this loop appends all of them and pipeline_files subsequently downloads every candidate, defeating the request bound described above. Stop this loop when the candidate limit is reached.

        contents.each do |entry|
          next unless entry.type == "file" && entry.name.match?(YAML_PATTERN)

          candidates << cleaned_path(dir, entry.name)
        end

• Files reviewed: 67/70 changed files
• Comments generated: 2
• Review effort level: Medium