如何在Azure DevOps环境分支控制中仅允许关联master分支的标签

Great question! Let's break down how to solve this problem step by step:

1. Fetching All Pipeline Resources via Azure DevOps API #

The standard branch control check does have access to all repository references used in the pipeline, and you can replicate this capability by calling the Azure DevOps Build API from your Azure Function. Here's how:

• When your custom check triggers, it receives context parameters like build.id, project.id, and organization.name (you can configure these to be passed to your function directly in the check settings).
• Use these parameters to call the Build Details API:

  GET https://dev.azure.com/{organizationName}/{projectId}/_apis/build/builds/{buildId}?api-version=7.1-preview.7
  

• In the response, look for the resources.repositories array — this contains every repository referenced by the pipeline (including template repositories). Each entry will include the ref value (e.g., refs/tags/0.0.1) and the repository ID/name you need for further validation.

2. Limitations of Environment Variables #

Predefined environment variables like BUILD_SOURCEBRANCH or BUILD_REPOSITORY_NAME only expose details about the main repository triggering the pipeline. They won't capture references from template repositories, so you can't rely on them to get a complete list of all resources used in the pipeline. The API is the only reliable way here.

3. Validating Tags Point to Master Branch Commits #

Once you have all repository refs from the API, implement this validation logic in your Azure Function:

• For each repository reference:
  • If the ref is a branch (refs/heads/*), verify it exactly matches refs/heads/master.
  • If the ref is a tag (refs/tags/*):
    1. Extract the tag name, then call the Git Tags API to get the commit ID it points to:

       GET https://dev.azure.com/{organizationName}/{projectId}/_apis/git/repositories/{repoId}/tags/{tagName}?api-version=7.1-preview.1
       

    2. Check if this commit exists in the master branch's history. You can do this either:
       • By running a Git command (if your function environment has Git installed):

         git clone --depth 100 https://dev.azure.com/{org}/{proj}/_git/{repoName}
         git merge-base --is-ancestor {commitId} master
         

         A return code of 0 means the commit is an ancestor of master (i.e., part of the master branch history).
       • Or via the Azure DevOps Commits API to confirm the commit falls within the master branch's commit range.

4. Can Custom Checks Reuse the Standard Branch Control Logic? #

Unfortunately, the internal logic powering the standard "Branch Control" check isn't exposed as a public API for custom checks. You'll need to build the validation logic yourself using the APIs mentioned above, but it's fully feasible to replicate the exact same behavior as the built-in check.

Pro Tips #

• Ensure the service principal used by your Azure Function has Read permissions for Builds and Git Repositories in your Azure DevOps project — otherwise, your API calls will fail due to insufficient access.
• Add error handling for edge cases like deleted tags/commits to avoid false validation results.

内容的提问来源于stack exchange，提问作者Andriy