必须向 Azure Pipelines 授予对存储库的访问权限，以触发其生成并在生成期间提取其代码。 通常，管道有权访问同一项目中的存储库。 但是，如果要访问其他项目中的存储库，则需要更新授予 作业访问令牌 的权限。

CI 触发器

持续集成 (CI) 触发器会导致管道在将更新推送到指定分支或推送指定的标记时运行。

如果使用 模板 创作 YAML 文件，则只能在管道的 main YAML 文件中指定触发器。 不能在模板文件中指定触发器。

对于使用 exclude 或 batch 的更复杂的触发器，必须使用完整语法，如以下示例所示。

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*
在上面的示例中，如果将更改推送到或推送到 main 任何发布分支，将触发管道。 但是，如果对以 old开头的版本分支进行更改，则不会触发它。
如果在没有 子句的情况下include指定子exclude句，则它等效于在 子句中include指定 * 。
除了在 branches 列表中指定分支名称外，还可以使用以下格式基于标记配置触发器：
trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}
如果未指定任何触发器，则默认值与编写时一样：
trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string
指定触发器时，它将替换默认的隐式触发器，并且只有推送到显式配置为包含的分支才会触发管道。 首先处理包含，然后从该列表中删除排除项。
批处理 CI 运行
如果有许多团队成员经常上传更改，则可能需要减少启动的运行次数。
如果将 设置为 batchtrue，则当管道运行时，系统将等待运行完成，然后启动另一个运行，其中包含尚未生成的所有更改。
# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main
batch 存储库资源触发器不支持 。
为了阐明此示例，我们假设对 main 的推送A导致上述管道运行。 当该管道正在运行时，会向存储库进行额外的推送 B 和 C 操作。 这些更新不会立即启动新的独立运行。 但是，在完成第一次运行后，在该时间点之前的所有推送将批处理在一起，并启动新的运行。
如果管道有多个作业和阶段，则在第二次运行开始之前，通过完成或跳过其所有作业和阶段，首次运行仍应达到终端状态。 因此，在具有多个阶段或审批的管道中使用此功能时，必须小心谨慎。 如果希望在这种情况下批处理生成，建议将 CI/CD 进程拆分为两个管道 - 一个用于生成 (批处理) ，一个用于部署。
可以指定要包含或排除的文件路径。
# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md
指定路径时，如果使用的是 Azure DevOps Server 2019.1 或更低版本，则必须显式指定要触发的分支。 不能仅使用路径筛选器触发管道;还必须具有分支筛选器，并且与路径筛选器匹配的已更改文件必须来自与分支筛选器匹配的分支。 如果使用 Azure DevOps Server 2020 或更高版本，可以省略branches以结合路径筛选器筛选所有分支。
路径筛选器支持通配符。 例如，可以包含与 匹配 src/app/**/myapp*的所有路径。 指定路径筛选器时，可以使用 (**、 *或 的?)野生卡字符。
始终相对于存储库的根目录指定路径。
如果未设置路径筛选器，则默认情况下会隐式包含存储库的根文件夹。
如果排除某个路径，则不能包含该路径，除非将其限定为更深层的文件夹。 例如，如果排除 /tools ，则可以包括 /tools/trigger-runs-on-these
路径筛选器的顺序并不重要。
Git 中的路径 区分大小写。 请确保使用与实际文件夹相同的大小写。
不能在路径中使用 变量 ，因为触发器触发) 后，会在运行时 (计算变量。
除了按上一部分所述在 branches 列表中指定标记外，还可以直接指定要包括或排除的标记：
# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0
如果未指定任何标记触发器，则默认情况下，标记不会触发管道。
如果结合分支筛选器指定标记，则满足分支筛选器或满足标记筛选器时将触发触发器。 例如，如果推送的标记满足分支筛选器，即使标记筛选器排除了该标记，管道也会触发，因为推送满足分支筛选器。
选择退出 CI
禁用 CI 触发器
可以通过指定 trigger: none完全退出 CI 触发器。
# A pipeline with no CI trigger
trigger: none
将更改推送到分支时，将评估该分支中的 YAML 文件，以确定是否应启动 CI 运行。
YAML 管道在 TFS 中不可用。
如果希望在用户签入代码时运行生成，请在“触发器”选项卡上选择“启用持续集成”以启用此触发器。
如果有许多团队成员经常上传更改，并且希望减少正在运行的生成数，请选择此检查框。 如果选择此选项，则当生成正在运行时，系统将等待运行完成，然后将尚未生成的所有更改的另一个运行排队。
可以批量更改并一起生成它们。
如果将批处理用于多阶段 YAML 管道，则运行必须达到终端状态，然后才能启动下一个运行。 这通常是不可取的，因为多阶段管道可能会经历审批和长时间运行的部署阶段。 在这些情况下，建议遵循以下解决方案之一：
不使用批处理
将管道拆分为两个单独的管道 - 一个用于 CI，一个用于 CD
在阶段上设置适当的条件以跳过它们并使运行快速终止
分支筛选器
可以指定要在其中触发生成的分支。 如果要使用通配符，请键入分支规范 (例如， features/modules/*) 然后按 Enter。
路径筛选器
如果 Git 存储库位于 Azure Repos 或 TFS 中，则还可以指定路径筛选器来减少要触发生成的文件集。
始终相对于存储库的根目录指定路径。
如果未设置路径筛选器，则默认情况下会隐式包含存储库的根文件夹。
如果排除路径，则也不能包含该路径，除非将其限定为更深的文件夹。 例如，如果排除 /tools ，则可以包括 /tools/trigger-runs-on-these
路径筛选器的顺序并不重要。
Git 中的路径区分大小写。 请务必使用与真实文件夹相同的大小写。
例如，你希望生成由功能分支中 main 和大多数（而不是全部）的更改触发。 你也不希望通过对 tools 文件夹中文件的更改触发生成。
跳过单个推送的 CI
还可以告诉 Azure Pipelines 跳过运行推送通常会触发的管道。 ***NO_CI***只需在消息中包含属于推送的任何提交，Azure Pipelines 将跳过此推送的运行 CI。
还可以告诉 Azure Pipelines 跳过运行推送通常会触发的管道。 [skip ci]只需在消息或说明中包含推送中的任何提交，Azure Pipelines 将跳过此推送的运行 CI。 还可以使用以下任何变体。
[skip ci] 或 [ci skip]
skip-checks: true 或 skip-checks:true
[skip azurepipelines] 或 [azurepipelines skip]
[skip azpipelines] 或 [azpipelines skip]
[skip azp] 或 [azp skip]
***NO_CI***
在条件中使用触发器类型
根据启动运行的触发器类型，在管道中运行不同的步骤、作业或阶段是一种常见方案。 可以使用系统变量 Build.Reason执行此操作。 例如，将以下条件添加到步骤、作业或阶段，以将其从 PR 验证中排除。
condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
创建新分支时触发器的行为
通常为同一存储库配置多个管道。 例如，你可能有一个管道用于生成应用的文档，另一个管道用于生成源代码。 可以在每个管道中配置相应的分支筛选器和路径筛选器的 CI 触发器。 例如，你可能希望在将更新推送到文件夹时触发一个管道，在将更新推送到 docs 应用程序代码时触发另一个管道。 在这些情况下，需要了解创建新分支时管道是如何触发的。
下面是将与分支筛选器) 匹配的新分支 (推送到存储库时的行为：
如果管道具有路径筛选器，则仅当新分支更改了与该路径筛选器匹配的文件时，才会触发该路径筛选器。
如果管道没有路径筛选器，即使新分支中没有更改，也会触发它。
指定分支、标记或路径时，可以使用确切的名称或通配符。
通配符模式允许 * 匹配零个或多个字符并 ? 匹配单个字符。
如果在 YAML 管道中以 开头 * ，则必须将模式括在引号中，例如 "*-releases"。
对于分支和标记：

通配符可能出现在模式中的任何位置。
对于路径：

在 Azure DevOps Server 2022 及更高版本（包括Azure DevOps Services）中，通配符可能会出现在路径模式中的任何位置，你可以使用 * 或 ?。
在 2020 年及更低Azure DevOps Server中，可以包含*为最后一个字符，但它与单独指定目录名称没有任何不同。 不能包含在*路径筛选器的中间，也不得使用 ?。
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md
PR 触发器
拉取请求 (PR) 触发器会导致管道在打开拉取请求或推送更改时运行。 在 Azure Repos Git 中，此功能是使用分支策略实现的。 若要启用 PR 验证，请导航到所需分支的分支策略，并为该分支配置 生成验证策略 。 有关详细信息，请参阅 配置分支策略。
如果已打开 PR 并将更改推送到其源分支，则可能会运行多个管道：
目标分支的生成验证策略指定的管道将在合并提交 (拉取请求) 的源分支与目标分支之间的合并代码上运行，而不管是否存在其消息或说明包含[skip ci] (或其任何变体) 的推送提交。
如果没有 推送提交 的消息或说明包含 [skip ci] (或其任何变体) ，则为更改 PR 的源分支触发的管道。 如果至少有一个推送的提交包含 [skip ci]，则管道将不会运行。
最后，合并 PR 后，Azure Pipelines 将运行由推送到目标分支的 CI 管道，即使某些合并提交的消息或说明包含 [skip ci] (或其任何变体) 也是如此。
若要为 Azure Repos Git 存储库配置验证版本，你必须是其项目的项目管理员。
即使配置分支策略，草稿拉取请求也不会触发管道。
验证分叉的贡献
从Azure Repos分支生成拉取请求与在同一存储库或项目中生成拉取请求没有什么不同。 只能在项目所属的同一组织中创建分叉。
限制作业授权范围
Azure Pipelines 提供了多个安全设置来配置管道运行的作业授权范围。
将作业授权范围限制为当前项目
保护对 YAML 管道中存储库的访问
将作业授权范围限制为当前项目
Azure Pipelines 为当前项目设置提供两个 限制作业授权范围 ：
将作业授权范围限制为非发布管道的当前项目 - 此设置适用于 YAML 管道和经典生成管道。 此设置不适用于经典发布管道。
将作业授权范围限制为发布管道的当前项目 - 此设置仅适用于 经典发布管道 。
管道使用集合范围内的访问令牌运行，除非启用了管道类型的相关设置。 使用 “限制作业授权范围 ”设置，可以将所有管道的访问范围缩小到当前项目。 如果要访问组织中其他项目中的 Azure Repos Git 存储库，则可能会影响管道。
如果Azure Repos Git 存储库与管道位于不同的项目中，并且启用了管道类型的“限制作业授权范围”设置，则必须向第二个项目授予对管道的生成服务标识的权限。 有关详细信息，请参阅 管理生成服务帐户权限。
Azure Pipelines 提供了一个安全设置，用于配置管道运行的作业授权范围。
将作业授权范围限制为当前项目 - 此设置适用于 YAML 管道和经典生成管道。 此设置不适用于 经典发布管道。
管道使用集合范围的访问令牌运行，除非已启用 将作业授权范围限制为当前项目 。 此设置允许将所有管道的访问范围缩小到当前项目。 如果要访问组织中其他项目中的 Azure Repos Git 存储库，则可能会影响管道。
如果Azure Repos Git 存储库与管道位于不同的项目中，并且启用了“限制作业授权范围”设置，则必须向第二个项目授予对管道的生成服务标识的权限。 有关详细信息，请参阅作业授权范围。
有关 限制作业授权范围的详细信息，请参阅 了解作业访问令牌。
将作业授权范围限制为引用的 Azure DevOps 存储库
除非启用了将 作业授权范围限制 为引用的 Azure DevOps 存储库，否则管道可以访问授权项目中的任何 Azure DevOps 存储库 ，如上一节中所述。 启用此选项后，可以将所有管道的访问范围缩小为仅由 checkout 使用该存储库的管道作业中的步骤或 uses 语句显式引用的 Azure DevOps 存储库。
若要配置此设置，请导航到“管道”、“组织设置”或“项目设置”。 如果在组织级别启用，则设置将灰显，在项目设置级别不可用。

启用将作业授权范围限制为引用的 Azure DevOps 存储库时，YAML 管道必须显式引用要在管道中使用的任何Azure Repos Git 存储库，作为使用该存储库的作业中的签出步骤。 除非首先显式引用该存储库，否则无法使用脚本任务和 git 命令为 Azure Repos Git 存储库提取代码。
在启用了将作业授权范围限制为引用 Azure Repos的 Azure DevOps 存储库时，在管道中使用 git 存储库之前，存在一些例外情况，即无需显式引用该存储库。
如果管道中没有显式签出步骤，则就像有一个步骤一 checkout: self 样，存储库 self 已签出。
如果使用脚本对公共项目中的存储库执行只读操作，则无需在步骤 checkout 中引用公共项目存储库。
如果使用向存储库提供自己的身份验证的脚本（例如 PAT），则无需在步骤中 checkout 引用该存储库。
例如，启用“将作业授权范围限制为引用的 Azure DevOps 存储库”时，如果管道位于FabrikamProject/Fabrikam组织中的存储库中，并且你想要使用脚本来检查FabrikamProject/FabrikamTools存储库，则必须在步骤中或语句uses中checkout引用此存储库。
如果已在使用签出步骤签出 FabrikamTools 管道中的存储库，则可以随后使用脚本与该存储库进行交互。
steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it
在许多情况下，可以利用多存储库签出，无需使用脚本在管道中检查其他存储库。 有关详细信息，请参阅 在管道中签出多个存储库。
保护对 YAML 管道中存储库的访问
管道可以访问授权项目中的任何 Azure DevOps 存储库，如前面的 将作业授权范围限制为当前项目 部分所述，除非启用了 保护对 YAML 管道中的存储库的访问 。 启用此选项后，可以将所有管道的访问范围缩小到仅由 checkout 使用该存储库的管道作业中的步骤或 uses 语句显式引用的 Azure DevOps 存储库。
若要配置此设置，请导航到“管道”、“组织设置”或“项目设置”。 如果在组织级别启用，则设置将灰显，在项目设置级别不可用。

默认情况下，为 2020 年 5 月之后创建的新组织和项目启用保护对 YAML 管道中的存储库的访问。
启用“保护对 YAML 管道中的存储库的访问”后，YAML 管道必须显式引用要在管道中使用的任何Azure Repos Git 存储库，作为使用该存储库的作业中的签出步骤。 除非首先显式引用该存储库，否则无法使用脚本任务和 git 命令为 Azure Repos Git 存储库提取代码。
在启用 YAML 管道中保护对存储库的访问时，在管道中使用 Azure Repos git 存储库之前，存在一些例外情况，即无需显式引用该存储库。
如果管道中没有显式签出步骤，则就像有一个步骤一 checkout: self 样，存储库 self 已签出。
如果使用脚本对公共项目中的存储库执行只读操作，则无需在步骤 checkout 中引用公共项目存储库。
如果使用向存储库提供自己的身份验证的脚本（例如 PAT），则无需在步骤中 checkout 引用该存储库。
例如，启用“在 YAML 管道中保护对存储库的访问”时，如果管道位于FabrikamProject/Fabrikam组织的存储库中，并且你想要使用脚本来检查FabrikamProject/FabrikamTools存储库，则必须在步骤中checkout引用此存储库，或者使用 uses 语句引用此存储库。
如果已在使用签出步骤签出 FabrikamTools 管道中的存储库，则可以随后使用脚本与该存储库进行交互。
steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it
在许多情况下，可以利用多存储库签出，无需使用脚本在管道中检查其他存储库。 有关详细信息，请参阅 在管道中签出多个存储库。
触发管道时，Azure Pipelines 会从 Azure Repos Git 存储库拉取源代码。 你可以控制其发生方式的各个方面。
在管道中包含签出步骤时，我们将运行以下命令： git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1。
如果这不能满足你的需求，你可以选择通过 checkout: none 排除内置签出，然后使用脚本任务执行你自己的签出。
Git 的首选版本
Windows 代理附带了自己的 Git 副本。
如果希望提供自己的 Git 而不是使用包含的副本，请将 设置为 System.PreferGitFromPathtrue。
在非 Windows 代理上，此设置始终为 true。
如果要签出单个存储库，默认情况下，源代码将签出到名为 的 s目录中。 对于 YAML 管道，可以通过使用 path指定checkout来更改此设置。 指定的路径相对于 $(Agent.BuildDirectory)。 例如：如果签出路径值为 mycustompath 且 $(Agent.BuildDirectory) 为 C:\agent\_work\1，则源代码将签出到 C:\agent\_work\1\mycustompath中。
如果使用多个 checkout 步骤并签出多个存储库，并且未使用 path显式指定文件夹，则每个存储库都放置在以存储库命名的 的 s 子文件夹中。 例如，如果检查两个名为 tools 和 code的存储库，则源代码将签出到 C:\agent\_work\1\s\tools 和 C:\agent\_work\1\s\code中。
请注意，签出路径值不能设置为高于 $(Agent.BuildDirectory)的任何目录级别，因此 path\..\anotherpath 将导致有效的签出路径 (即 C:\agent\_work\1\anotherpath) ，但类似 的值 ..\invalidpath 不会 (即 C:\agent\_work\invalidpath) 。
可以在管道的path“签出”步骤中配置设置。
steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch
此设置在经典编辑器中不可配置。 源代码将签出到名为 s的目录中，该目录相对于 $(Agent.BuildDirectory)。 例如：如果 $(Agent.BuildDirectory) 为 C:\agent\_work\1，则源代码将签出到 C:\agent\_work\1\mycustompath中。
如果要从子模块下载文件，submodules可以在管道的 Checkout 步骤中配置 设置。
steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch
包含在上面指定的 Azure Repos Git 存储库所在的同一项目中。  代理用于从 main 存储库获取源的相同凭据也用于获取子模块的源。
通过使用相对于 main 存储库的 URL 添加。 例如：
此将签出： git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber
在此示例中，子模块引用同一 Azure DevOps 组织中 (FabrikamFiber) 存储库，但在 FabrikamFiberProject)  (不同的项目中。  代理用于从 main 存储库获取源的相同凭据也用于获取子模块的源。 这要求作业访问令牌有权访问第二个项目中的存储库。 如果如上一部分所述限制作业访问令牌，则无法执行此操作。 可以通过以下方法允许作业访问令牌访问第二个项目中的存储库： () 显式授予对第二个项目中的项目生成服务帐户的访问权限，或者 (b) 使用集合范围的访问令牌而不是整个组织的项目范围令牌。 有关这些选项及其安全隐患的详细信息，请参阅 访问存储库、项目和其他资源。
此名称不会签出： git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber
在某些情况下，无法使用 “签出子模块 ”选项。
你可能有这样一种情况：需要一组不同的凭据才能访问子模块。
例如，如果main存储库和子模块存储库不存储在同一 Azure DevOps 组织中，或者作业访问令牌无权访问不同项目中的存储库，则可能会发生这种情况。
如果无法使用 “签出子模块 ”选项，则可以改用自定义脚本步骤来提取子模块。
首先， (PAT) 获取个人访问令牌，并使用 作为 pat:前缀。
接下来，对此前缀字符串进行 base64 编码 ，以创建基本身份验证令牌。
最后，将此脚本添加到管道：
git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive
请务必将“<BASE64_ENCODED_STRING>”替换为 Base64 编码的“pat：token”字符串。
在项目或生成管道中使用机密变量来存储生成的基本身份验证令牌。
使用该变量在上述 Git 命令中填充机密。
问：为什么不能在代理上使用 Git 凭据管理器？答： 在专用生成代理上安装的 Git 凭据管理器中存储子模块凭据通常无效，因为每当更新子模块时，凭据管理器可能会提示你重新输入凭据。 当无法进行用户交互时，在自动生成期间，这是不可取的。
提取 Git 存储库的内容时， --tags 签出步骤使用 选项。 这会导致服务器提取所有标记以及这些标记指向的所有对象。 这会增加在管道中运行任务的时间，尤其是在具有大量标记的大型存储库时。 此外，即使启用浅取选项，签出步骤也会同步标记，因此可能会破坏其用途。 为了减少从 Git 存储库提取或提取的数据量，Microsoft 添加了一个新的签出选项来控制同步标记的行为。 此选项在经典管道和 YAML 管道中均可用。
是否在签出存储库时同步标记可以通过设置 fetchTags 属性在 YAML 中配置，并在 UI 中通过配置 同步标记 设置来配置。
对于在 2022 年 9 月发布的 Azure DevOps 冲刺 209 发布之前创建的现有管道，同步标记的默认值与添加 同步标记 选项之前的现有行为相同，即 true。
对于在 Azure DevOps 冲刺版本 209 之后创建的新管道，同步标记的默认值为 false。
如果在步骤中checkout显式设置fetchTags，该设置优先于管道设置 UI 中配置的设置。
你可能想要限制在历史记录中下载的距离。 这实际上会导致 git fetch --depth=n。 如果存储库很大，此选项可能会提高生成管道的效率。 如果存储库已使用很长时间并且具有相当大的历史记录，则存储库可能很大。 如果添加和以后删除了大型文件，则它也可能很大。
在 2022 年 9 月 Azure DevOps sprint 209 更新 后创建的新管道默认启用 浅层提取 ，并配置为深度为 1。 以前默认不是浅层提取。 若要检查管道，请在管道设置 UI 中查看浅层提取设置，如以下部分所述。
可以在管道的fetchDepth“签出”步骤中配置设置。
steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch
还可以通过在管道设置 UI 中设置 浅层深度 选项来配置提取深度。
编辑 YAML 管道，然后选择 “更多操作”、“ 触发器”。
选择 “YAML”、“ 获取源”。
配置 浅层提取 设置。 取消选中“浅层提取”以禁用浅取，或检查框并输入“深度”以启用浅取。
管道启动时，要生成的分支将解析为提交 ID。 然后，代理提取分支并签出所需的提交。 分支解析为提交 ID和代理执行签出之间有一个小窗口。 如果分支更新迅速，并且你为浅层提取设置了非常小的值，则代理尝试检查它时，提交可能不存在。如果发生这种情况，请增加浅层提取深度设置。
你可能想要跳过提取新提交。 在需要以下情况时，此选项非常有用：
使用自己的自定义选项进行 Git 初始化、配置和提取。
使用生成管道仅运行自动化 (例如，某些脚本) 不依赖于版本控制中的代码。
在运行生成之前，可以执行不同形式的清理自承载代理的工作目录。
通常，为了提高自承载代理的性能，请不要清理存储库。 在这种情况下，若要获得最佳性能，请确保通过禁用用于生成的任务或工具的任何 “清理 ”选项，以增量方式生成。
如果确实需要清理存储库 (例如，以避免以前生成) 中的剩余文件导致的问题，选项如下。
如果使用 Microsoft 托管的代理 ，则清理无效，因为每次都会获得新的代理。
可以在管道的clean“签出”步骤中配置设置。
steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch
当 设置为 true 时clean，生成管道将执行中任何更改$(Build.SourcesDirectory)的撤消操作。 更具体地说，以下 Git 命令是在提取源之前执行的。
git clean -ffdx
git reset --hard HEAD
有关更多选项，可以配置workspace作业的设置。
jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
这提供了以下干净选项。
outputs：与上一签出任务中所述的清理设置相同的操作，以及：删除并重新创建 $(Build.BinariesDirectory)。 请注意，始终在 $(Build.ArtifactStagingDirectory) 每次生成之前删除并重新创建 和 $(Common.TestResultsDirectory) ，而不考虑这些设置中的任何一个。
资源：删除并重新创建 $(Build.SourcesDirectory)。 这会导致为每个生成初始化新的本地 Git 存储库。
all：删除并重新创建 $(Agent.BuildDirectory)。 这会导致为每个生成初始化新的本地 Git 存储库。
源：生成管道执行中 $(Build.SourcesDirectory)任何更改的撤消操作。 更具体地说，以下 Git 命令是在提取源之前执行的。
git clean -ffdx
git reset --hard HEAD
源和输出目录：与上述 “源” 选项相同的操作，以及：删除并重新创建 $(Build.BinariesDirectory)。 请注意，始终在 $(Build.ArtifactStagingDirectory) 每次生成之前删除并重新创建 和 $(Common.TestResultsDirectory) ，而不考虑这些设置中的任何一个。
源目录：删除并重新创建 $(Build.SourcesDirectory)。 这会导致为每个生成初始化新的本地 Git 存储库。
所有生成目录：删除并重新创建 $(Agent.BuildDirectory)。 这会导致为每个生成初始化新的本地 Git 存储库。
在 标记格式 中，可以使用作用域为“全部”的用户定义变量和预定义变量。例如：
$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)
前四个变量是预定义的。 My.Variable 可以在 “变量”选项卡上定义。
生成管道使用 Git 标记标记源。
某些生成变量可能会生成不是有效标签的值。 例如，和 $(Build.DefinitionName) 等$(Build.RequestedFor)变量可以包含空格。 如果值包含空格，则不会创建标记。
生成管道标记源后，带有 Git ref refs/tags/{tag} 的项目会自动添加到已完成的生成中。 这为团队提供了额外的可跟踪性和更方便用户的方式，用于从生成导航到生成的代码。 标记被视为生成项目，因为它是由生成生成的。 手动或通过保留策略删除生成时，也会删除 标记。
常见问题解答
与Azure Repos集成相关的问题分为三类：
失败的触发器： 将更新推送到存储库时，管道未触发。
签出失败： 我的管道正在触发，但在签出步骤中失败。
版本错误： 我的管道运行，但它使用的是源/YAML 的意外版本。
失败的触发器
我刚刚创建了一个包含 CI/PR 触发器的新 YAML 管道，但未触发该管道。
请遵循以下每个步骤对失败的触发器进行故障排除：
你的 YAML CI 或 PR 触发器是否 被 UI 中的管道设置覆盖？ 编辑管道时，选择 “...” ，然后选择 “触发器”。
选中“ 从此处替代 YAML 触发器 ”设置，了解存储库可用的触发器类型 (持续集成 或 拉取请求验证) 。
你是在 YAML 文件还是存储库的分支策略中配置 PR 触发器？ 对于 Azure Repos Git 存储库，无法在 YAML 文件中配置 PR 触发器。 需要使用 分支策略。
管道是否已暂停或禁用？ 打开管道的编辑器，然后选择“设置”以检查。 如果暂停或禁用管道，则触发器不起作用。
是否已在正确的分支中更新 YAML 文件？ 如果将更新推送到分支，则同一分支中的 YAML 文件将控制 CI 行为。 如果将更新推送到源分支，则源分支与目标分支合并产生的 YAML 文件将控制 PR 行为。 请确保正确分支中的 YAML 文件具有必要的 CI 或 PR 配置。
是否已正确配置触发器？ 定义 YAML 触发器时，可以为分支、标记和路径指定 include 和 exclude 子句。 确保 include 子句与提交的详细信息匹配，并且 exclude 子句不会排除它们。 检查触发器的语法，并确保其准确。
是否在定义触发器或路径时使用了变量？ 不支持。
是否对 YAML 文件使用了模板？ 如果是这样，请确保在 main YAML 文件中定义了触发器。 不支持在模板文件中定义的触发器。
是否排除了将更改推送到的分支或路径？ 通过将更改推送到包含分支中的包含路径进行测试。 请注意，触发器中的路径区分大小写。 在触发器中指定路径时，请确保使用与实际文件夹相同的大小写。
你刚刚推送了一个新分支吗？ 如果是这样，新分支可能不会启动新的运行。 请参阅“创建新分支时触发器的行为”部分。
我的 CI 或 PR 触发器工作正常。 但是，他们现在停止工作了。
首先完成上一个问题中的故障排除步骤。 然后，执行以下附加步骤：
PR 中是否有合并冲突？ 对于未触发管道的 PR，请将其打开并检查它是否具有合并冲突。 解决合并冲突。
处理推送或 PR 事件时是否遇到延迟？ 通常可以通过查看该问题是特定于单个管道还是项目中所有管道或存储库通用来验证此问题。 如果对任何存储库的推送或 PR 更新出现此症状，则可能在处理更新事件时遇到延迟。 在 状态页上检查我们是否遇到服务中断。 如果状态页显示问题，则我们的团队必须已开始处理该问题。 经常查看页面以获取有关该问题的更新。
我不希望用户在更新 YAML 文件时替代触发器的分支列表。 如何执行此操作？
有权贡献代码的用户可以更新 YAML 文件并包括/排除其他分支。 因此，用户可以在其 YAML 文件中包含自己的功能或用户分支，并将该更新推送到功能或用户分支。 这可能会导致针对该分支的所有更新触发管道。 如果要阻止此行为，可以：
在 Azure Pipelines UI 中编辑管道。
导航到 “触发器 ”菜单。
从此处选择“替代 YAML 持续集成触发器”。
指定要为触发器包含或排除的分支。
执行这些步骤时，将忽略 YAML 文件中指定的任何 CI 触发器。
我的 YAML 管道中有多个存储库。 如何为每个存储库设置触发器？
请参阅使用多个存储库中的触发器。
在签出步骤期间，我在日志文件中看到以下错误。 如何解决问题？
remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128
请遵循以下每个步骤对签出失败进行故障排除：
存储库是否仍然存在？ 首先，通过在 “存储库 ”页中打开它，确保它确实存在。
是否使用脚本访问存储库？ 如果是，检查“将作业授权范围限制为引用的 Azure DevOps 存储库”设置。 启用“将作业授权范围限制为引用的 Azure DevOps 存储库”后，将无法使用脚本检查Azure Repos Git 存储库，除非先在管道中显式引用它们。
管道的 作业授权范围 是什么？
如果范围是 集合：
这可能是间歇性错误。 重新运行管道。
某人可能已删除对 Project Collection 生成服务帐户的访问权限。
转到存储库所在的项目的 “项目设置 ”。 选择“存储库>>特定存储库”，然后选择“安全性”。
检查 项目集合生成服务 (集合名称)  是否存在于用户列表中。
检查该帐户是否具有 “创建标记” 和 “读取 ”访问权限。
某人可能已删除对 Project Build Service 帐户的访问权限。
转到存储库所在的项目的 “项目设置 ”。 选择“存储库>>特定存储库”，然后选择“安全性”。
检查用户列表中是否存在 your-project-name 生成服务 (your-collection-name)  。
检查该帐户是否具有 “创建标记” 和 “读取 ”访问权限。
对于 CI 触发器，将评估正在推送的分支中的 YAML 文件，以查看是否应运行 CI 生成。
对于 PR 触发器，将评估合并 PR 的源分支和目标分支所产生的 YAML 文件，以查看是否应运行 PR 生成。
计划的触发器
管道完成触发器