Azure DevOps Services
Azure Pipelines 可以自动生成和验证每个拉取请求并提交到 Bitbucket 云存储库。 本文介绍如何配置 Bitbucket Cloud 和 Azure Pipelines 之间的集成。
Bitbucket 和 Azure Pipelines 是两个独立的服务，可以很好地集成在一起。 Bitbucket Cloud 用户不会自动获得对 Azure Pipelines 的访问权限。 必须将它们显式添加到 Azure Pipelines。
访问 Bitbucket 存储库
通过首先选择 Bitbucket 云存储库，然后在该存储库中选择一个 YAML 文件来创建新管道。 YAML 文件所在的存储库称为
self
存储库。 默认情况下，这是管道生成的存储库。
稍后可将管道配置为检查不同的存储库或多个存储库。 若要了解如何执行此操作，请参阅
多存储库签出
。
通过首先为存储库类型选择
Bitbucket Cloud
，然后选择有权访问的存储库之一来创建新管道。
必须向 Azure Pipelines 授予对存储库的访问权限，才能在生成期间提取代码。 此外，设置管道的用户必须具有 Bitbucket 的管理员访问权限，因为该标识用于在 Bitbucket 中注册 Webhook。
有 2 种身份验证类型可用于在创建管道时向 Azure Pipelines 授予对 Bitbucket 云存储库的访问权限。
身份验证类型
管道使用 运行
OAuth 身份验证
对于 Bitbucket 帐户中的存储库，OAuth 是最简单的身份验证类型。 Bitbucket 状态更新将代表你的个人 Bitbucket 标识执行。 若要使管道正常工作，存储库访问必须保持活动状态。
若要使用 OAuth，请在创建管道期间出现提示时登录到 Bitbucket。 然后，单击“
授权
”以使用 OAuth 进行授权。 OAuth 连接将保存在 Azure DevOps 项目中供以后使用，并在创建的管道中使用。
Azure DevOps Services用户界面可以加载的最大 Bitbucket 存储库数为 2，000。
生成和 Bitbucket 状态更新将代表你的个人标识执行。 要使内部版本正常工作，存储库访问权限必须保持活动状态。
若要创建密码连接，请访问 Azure DevOps 项目设置中的
服务连接
。
创建新的 Bitbucket 服务连接，并提供用于连接到 Bitbucket 云存储库的用户名和密码。
CI 触发器
持续集成 (CI) 触发器会导致管道在将更新推送到指定分支或推送指定的标记时运行。
如果使用
模板
创作 YAML 文件，则只能在管道的 main YAML 文件中指定触发器。 不能在模板文件中指定触发器。
对于使用
exclude
或
batch
的更复杂的触发器，必须使用完整语法，如以下示例所示。
# specific branch build
trigger:
branches:
include:
- main
- releases/*
exclude:
- releases/old*
在上面的示例中，如果将更改推送到 master 或任何发布分支，则会触发管道。 但是，如果对以 old开头的版本分支进行更改，则不会触发它。
如果指定子exclude句而不指定include子句，则它等效于在 子句中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 存储库资源触发器不支持。
为了阐明此示例，我们假设推送 A 到 master 导致上述管道运行。 当该管道正在运行时，会向存储库进行其他推送和C操作B。 这些更新不会立即启动新的独立运行。 但在第一次运行完成后，将一起批处理所有推送到该时间点，并启动新的运行。
如果管道有多个作业和阶段，则第一次运行仍应通过完成或跳过其所有作业和阶段来达到终端状态，然后才能开始第二个运行。 出于此原因，在具有多个阶段或审批的管道中使用此功能时，必须格外小心。 如果希望在这种情况下批处理生成，建议将 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 中的路径 区分大小写。 请务必使用与真实文件夹相同的大小写。
不能在路径中使用 变量 ，因为触发器触发) 后，会在运行时 (评估变量。
对于 Bitbucket Cloud 存储库，使用 branches 语法是指定标记触发器的唯一方法。 tags: Bitbucket 不支持语法。
选择退出 CI
禁用 CI 触发器
可以通过指定 trigger: none完全选择退出 CI 触发器。
# A pipeline with no CI trigger
trigger: none
将更改推送到分支时，将评估该分支中的 YAML 文件，以确定是否应启动 CI 运行。
启用生成过程中的 Batch 更改时，Build.SourceVersionMessage 变量不适用于 Bitbucket 存储库。
如果希望在用户签入代码时运行生成，请在“触发器”选项卡上选择“启用持续集成”以启用此触发器。
如果有许多团队成员经常上传更改，并且希望减少正在运行的生成数，请选中此检查框。 如果选择此选项，则当生成正在运行时，系统将等待运行完成，然后将尚未生成的所有更改的另一个运行排队。
可以批量更改并一起生成它们。
如果将批处理用于多阶段 YAML 管道，则运行必须达到终端状态，然后才能启动下一个运行。 这通常是不可取的，因为多阶段管道可能会经历审批和长时间运行的部署阶段。 在这些情况下，建议遵循以下解决方案之一：
不使用批处理
将管道拆分为两个单独的管道 - 一个用于 CI，一个用于 CD
在阶段上设置适当的条件以跳过它们并使运行快速终止
分支筛选器
可以指定要触发生成的分支。 如果要使用通配符，请键入分支规范 (例如， features/modules/*) 然后按 Enter。
路径筛选器
如果 Git 存储库位于 Azure Repos 或 TFS 中，则还可以指定路径筛选器来减少要触发生成的文件集。
始终相对于存储库的根目录指定路径。
如果未设置路径筛选器，则默认情况下会隐式包含存储库的根文件夹。
如果排除某个路径，则不能包含该路径，除非将其限定为更深层的文件夹。 例如，如果排除 /tools ，则可以包括 /tools/trigger-runs-on-these
路径筛选器的顺序并不重要。
Git 中的路径区分大小写。 请确保使用与实际文件夹相同的大小写。
例如，你希望生成由主分支以及大多数（但不是全部）功能分支的更改触发。 你也不希望通过对 tools 文件夹中文件的更改触发生成。
跳过单个提交的 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"。
对于分支和标记：
