在 Cloud Manager 中添加外部存储库 external-repositories

了解如何将外部存储库添加到 Cloud Manager。Cloud Manager支持与GitHub Enterprise、GitLab和Bitbucket存储库集成。

客户现在还可以将其Azure DevOps Git存储库载入到Cloud Manager中,并支持现代Azure DevOps和旧版VSTS (Visual Studio Team Services)存储库。

  • Edge Delivery Services 用户可以使用已加入的存储库来同步和部署网站代码。
  • 对于 AEM as a Cloud Service 和 Adobe Managed Services (AMS) 用户,该存储库可以链接到全栈和前端两种管道。

配置外部存储库

在 Cloud Manager 中配置外部存储库包括三个步骤:

  1. 将外部存储库添加到选择的程序。
  2. 将已验证的外部存储库链接到管道
  3. 将webhook配置为外部存储库。

添加一个外部存储库 add-ext-repo

NOTE
外部存储库无法链接到配置管道。
  1. my.cloudmanager.adobe.com 登录 Cloud Manager 并选择适当的组织。

  2. 在​ 我的程序 ​控制台上,选择要将外部存储库链接到的程序。

  3. 在侧菜单的​ 程序 ​下,单击 文件夹大纲图标 存储库

    存储库页面

  4. 在​ 存储库 ​页面的右上角附近,点击​ 添加存储库

  5. 在​ 添加存储库 ​对话框中,选择​ 专用存储库,将外部 Git 存储库链接到您的程序。

    添加自己的存储库

  6. 在每个相应的字段中,提供有关存储库的以下详细信息:

    table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2
    字段 描述
    存储库名称 必需。为您的新存储库取一个富有表现力的名称。
    存储库 URL 必需。存储库的 URL。

    如果您使用的是GitHub托管的存储库,则路径必须以.git结尾。
    例如,https://github.com/org-name/repo-name.git (URL路径仅用于图示)。

    如果您使用外部存储库,则必须使用以下 URL 路径格式:
    https://git-vendor-name.com/org-name/repo-name.git

    https://self-hosted-domain/org-name/repo-name.git
    ,并与您的 Git 供应商匹配。
    选择存储库类型

    必需。选择正在使用的存储库类型:

    • GitHub(GitHub Enterprise和GitHub的自托管版本)
    • GitLabgitlab.com和GitLab的自托管版本)
    • Bitbucket(仅支持bitbucket.org (云版本))。 Bitbucket的自托管版本从2024年2月15日开始被弃用。)
    • Azure DevOps (dev.azure.com)

    如果上面的存储库 URL 路径包含 Git 供应商名称,例如 GitLab 或 Bitbucket,则存储库类型已为您预先选择。

    描述 可选。存储库的详细描述。
  7. 选择​ 保存 ​以添加存储库。

    现在,提供访问令牌以验证外部存储库的所有权。

  8. 在​ 私有存储库所有权验证 ​对话框中,提供用于验证外部存储库所有权的访问令牌,以便您能够访问它,然后单击​ 验证

    为存储库选择现有的访问令牌
    为Bitbucket存储库选择现有的访问令牌(仅供说明)。

GitHub企业版
table 0-row-2 1-row-2 2-row-2
访问令牌选项 描述
使用现有的访问令牌 如果您已经为贵组织提供了存储库访问令牌,并且有权访问多个存储库,则可以选择一个现有令牌。使用​ 令牌名称 ​下拉列表,选择要应用到存储库的令牌。否则,添加一个新的访问令牌。
添加新的访问令牌
  • 在​ 令牌名称 ​文本字段中,键入要创建的访问令牌的名称。

  • 按照GitHub文档中的说明创建个人访问令牌。

  • GitHub企业个人访问令牌(PAT)所需的权限
    这些权限确保Cloud Manager可以验证拉取请求、管理提交状态检查以及访问必要的存储库详细信息。
    在GitHub Enterprise中生成PAT时,请确保它包含以下存储库权限:

    • 拉取请求(读取和写入)
    • 提交状态(读取和写入)
    • 存储库元数据(只读)
  • 在​ 访问令牌 ​字段中,粘贴刚刚创建的令牌。

验证后,外部存储库即可使用并链接到管道。

另请参阅管理访问令牌

GitLab
table 0-row-2 1-row-2 2-row-2
访问令牌选项 描述
使用现有的访问令牌 如果您已经为贵组织提供了存储库访问令牌,并且有权访问多个存储库,则可以选择一个现有令牌。使用​ 令牌名称 ​下拉列表,选择要应用到存储库的令牌。否则,添加一个新的访问令牌。
添加新的访问令牌
  • 在​ 令牌名称 ​文本字段中,键入要创建的访问令牌的名称。

  • 按照GitLab文档中的说明创建个人访问令牌。

  • GitLab个人访问令牌(PAT)所需的权限
    这些范围允许Cloud Manager访问验证和webhook集成所需的存储库数据和用户信息。
    在GitLab中生成PAT时,请确保它包括以下令牌范围:

    • api
    • read_user
  • 在​ 访问令牌 ​字段中,粘贴刚刚创建的令牌。

验证后,外部存储库即可使用并链接到管道。

另请参阅管理访问令牌

比特桶
table 0-row-2 1-row-2 2-row-2
访问令牌选项 描述
使用现有的访问令牌 如果您已经为贵组织提供了存储库访问令牌,并且有权访问多个存储库,则可以选择一个现有令牌。使用​ 令牌名称 ​下拉列表,选择要应用到存储库的令牌。否则,添加一个新的访问令牌。
添加新的访问令牌
  • 在​ 令牌名称 ​文本字段中,键入要创建的访问令牌的名称。

  • 使用Bitbucket文档创建存储库访问令牌。

  • Bitbucket个人访问令牌(PAT)所需的权限
    这些权限允许Cloud Manager访问存储库内容、管理拉取请求以及配置或响应webhook事件。
    在Bitbucket中创建应用程序密码时,请确保它包含以下必需的应用程序密码权限:

    • 存储库(只读)
    • 拉取请求(读取和写入)
    • Webhook(读写)
  • 在​ 访问令牌 ​字段中,粘贴刚刚创建的令牌。

验证后,外部存储库即可使用并链接到管道。

另请参阅管理访问令牌

Azure DevOps
table 0-row-2 1-row-2 2-row-2
访问令牌选项 描述
使用现有的访问令牌 如果您已经为贵组织提供了存储库访问令牌,并且有权访问多个存储库,则可以选择一个现有令牌。使用​ 令牌名称 ​下拉列表,选择要应用到存储库的令牌。否则,添加一个新的访问令牌。
添加新的访问令牌
  • 在​ 令牌名称 ​文本字段中,键入要创建的访问令牌的名称。

  • 使用Azure DevOps文档创建存储库访问令牌。

  • Azure DevOps个人访问令牌(PAT)所需的权限。
    这些权限允许Cloud Manager访问存储库内容、管理拉取请求以及配置或响应webhook事件。
    当您在Azure DevOps中创建应用程序密码时,请确保它包含以下必需的应用密码权限:

    • 代码(读取)
    • 代码(状态)
    • 拉取请求Threads(读写)
  • 在​ 访问令牌 ​字段中,粘贴刚刚创建的令牌。

验证后,外部存储库即可使用并链接到管道。

另请参阅管理访问令牌

将经过验证的外部存储库链接到管道 validate-ext-repo

  1. 添加或编辑管道:

    管道的源代码存储库和 Git 分支
    添加非生产管道对话框,其中包含选择的存储库和 Git 分支,

  2. 添加或编辑管道时,要指定新管道或现有管道的​ 源代码 ​位置,请从​ 存储库 ​下拉列表中选择要使用的外部存储库。

  3. Git 分支 ​下拉列表中,选择该分支作为管道的源。

  4. 单击​ 保存

TIP
有关在 Cloud Manager 中管理存储库的详细信息,请参阅 Cloud Manager 存储库

为外部存储库配置webhook configure-webhook

Cloud Manager允许您为已添加的外部Git存储库配置webhook。 请参阅添加外部存储库。 这些Webhook允许Cloud Manager接收与Git供应商解决方案中的其他操作相关的事件。

例如,Webhook允许Cloud Manager根据以下事件触发操作:

  • 创建拉取请求(PR) — 启动PR验证功能。
  • 推送事件 — 在“在Git上提交”触发器打开(启用)时启动管道。
  • 未来基于评论的操作 — 允许工作流,例如直接从PR部署到快速开发环境(RDE)。

GitHub.com上托管的存储库不需要Webhook配置,因为Cloud Manager直接通过GitHub应用程序集成。

对于已载入访问令牌的所有其他外部存储库 — 例如GitHub Enterprise、GitLab、Bitbucket和Azure DevOps - webhook配置可用,必须手动设置。

要为外部存储库配置webhook:

  1. my.cloudmanager.adobe.com 登录 Cloud Manager 并选择适当的组织。

  2. 在​ 我的程序 ​控制台上,选择要为其配置外部Git存储库的webhook的程序。

  3. 在页面左上角,单击 显示菜单图标 以显示左侧菜单。

  4. 在左侧菜单的​ 项目 ​标题下,单击 文件夹大纲图标 存储库

  5. 在​ 存储库 ​页面上,使用​ 类型 ​列引导您进行选择,找到所需的存储库,然后单击其旁边的 省略号 — 更多图标

    在下拉菜单中配置选定存储库的Webhook选项

  6. 从下拉菜单中,单击​ 配置Webhook

    配置Webhook对话框

  7. 在​ 配置Webhook ​对话框中,执行以下操作:

    1. 在​ Webhook URL ​字段旁边,单击 复制图标
      将URL粘贴为纯文本文件。 您的Git供应商的Webhook设置需要复制的URL。
    2. 在​ Webhook密码 ​令牌/密钥字段旁边,单击​ 生成,然后单击 复制图标
      将密码粘贴为纯文本文件。 您的Git供应商的Webhook设置需要复制的密钥。
  8. 单击​ 关闭

  9. 导航到您的Git供应商解决方案(GitHub Enterprise、GitLab、Bitbucket或Azure DevOps)。

    有关webhook配置的所有详细信息以及每个供应商所需的事件均可在添加外部存储库中获取。 在步骤8下,请参见选项卡表。

  10. 找到解决方案的​ Webhook ​设置部分。

  11. 将之前复制的Webhook URL粘贴到URL文本字段中。

    1. 将Webhook URL中的api_key查询参数替换为您自己的实际API密钥。

      要生成API密钥,您必须在Adobe Developer Console中创建集成项目。 有关完整详细信息,请参阅创建API集成项目

  12. 将您之前复制的Webhook密码粘贴到​ 密码(或​ 密钥,或​ 密码令牌)文本字段中。

  13. 配置webhook以发送Cloud Manager所需的事件。 使用下表确定Git提供商的正确事件。

GitHub企业版
table 0-row-1 1-row-1
必需的webhook事件

这些事件允许Cloud Manager响应GitHub活动,例如拉取请求验证、管道的基于推送的触发器或Edge Delivery Services代码同步。
确保将webhook设置为在下列必需的webhook事件上触发:

  • 拉取请求
  • 推送
  • 问题评论
GitLab
table 0-row-1 1-row-1
必需的webhook事件

这些webhook事件允许Cloud Manager在推送代码或提交合并请求时触发管道。 它们还跟踪与拉取请求验证相关的注释(通过注释事件)。
确保将webhook设置为在下列必需的webhook事件上触发

  • 推送事件
  • 合并请求事件
  • 注释事件
比特桶
table 0-row-1 1-row-1
必需的webhook事件

这些事件可确保Cloud Manager能够验证拉取请求、响应代码推送并与注释交互以协调管道。
确保将webhook设置为在下列必需的webhook事件上触发

  • 拉取请求:已创建
  • 拉取请求:已更新
  • 拉取请求:已合并
  • 拉取请求:评论
  • 存储库:推送
Azure DevOps
table 0-row-1 1-row-1
所需的webhook事件和身份验证

这些事件可确保Cloud Manager能够验证拉取请求、响应代码推送并与注释交互以协调管道。
确保将webhook设置为在下列必需的webhook事件上触发

  • 推送的代码
  • 拉取请求已评论
  • 已创建拉取请求
  • 拉取请求已更新

设置身份验证:
1。 在​ 基本身份验证用户名 ​字段中,键入cloudmanager
2。在​ 基本身份验证密码 ​字段中,键入从Cloud Manager用户界面生成的Webhook密码。

使用Webhook验证拉取请求

正确配置Webhook后,Cloud Manager会自动触发存储库的管道执行或拉取请求(PR)验证检查。

具体行为因您使用的Git提供商而异,如下所述。

GitHub企业版

创建检查后,它类似于下面的屏幕快照。 与GitHub.com的主要区别在于GitHub.com使用检查运行,而GitHub Enterprise(使用个人访问令牌)生成提交状态:

提交状态以指示GitHub Enterprise上的PR验证过程

GitLab

GitLab交互仅依赖于评论。 验证开始时,将添加注释。 验证完成(无论成功还是失败)后,将移除初始注释,并替换为包含验证结果或错误详细信息的新注释。

运行代码质量验证时:

运行代码质量验证时

完成冷质量验证时:

冷质量验证完成后

当代码质量验证失败并出现错误时:

当代码质量验证失败并出现错误

当代码质量验证因客户问题而失败时:

当代码质量验证因客户问题而失败时

比特桶

运行代码质量验证时:

正在运行代码质量验证时的 状态

使用提交状态来跟踪PR验证进度。 在以下示例中,屏幕截图显示了当代码质量验证因客户问题而失败时将发生的情况。 添加带有详细错误信息的注释,并创建提交检查,其中显示故障(在右侧可见):

Bitbucket的 拉取请求验证状态

Azure DevOps

Azure DevOps通过状态检查跟踪拉取请求验证。 当Cloud Manager运行拉取请求验证时,它将添加显示在Azure DevOps拉取请求界面中的状态检查。

在代码质量验证期间,状态检查会显示该流程正在进行中:

使用webhooks-1 对拉取请求进行 Azure DevOps验证

代码质量验证完成后,状态检查将更新以反映结果:

使用webhooks-2 对拉取请求进行 Azure DevOps验证

如果验证失败,状态检查详细信息中会提供详细的错误信息。 您可以单击状态检查以在Cloud Manager中查看完整的验证结果。

使用webhooks-3 对拉取请求进行 Azure DevOps验证

对于拉取请求注释和反馈,Cloud Manager会直接将注释添加到Azure DevOps中的拉取请求,其中包含验证详细信息以及所需的任何必要操作。

使用webhooks-4 对拉取请求进行 Azure DevOps验证

webhook问题疑难解答

  • 确保Webhook URL包含有效的API密钥。
  • 检查是否在Git供应商设置中正确配置了webhook事件。
  • 如果PR验证或管道触发器不起作用,请验证Cloud Manager和Git供应商中的Webhook密码是否为最新。
recommendation-more-help
c6cdc82b-cee9-48e0-a6ee-48149d5e72c3