UiPath™ Automation Ops™ - 管道

Automation Ops™ - 管道提供了一种简单的方法来设置持续集成/持续交付系统，从而管理外部存储库（例如 Github 或 Azure DevOps）中的自动化项目代码。

管道包含一组步骤，这些步骤依赖于用于更改环境中代码的自动化流程。 这些流程（也称为管道流程）使用管道活动包。 要查看这些管道流程，用户必须有权访问包含这些流程的 Orchestrator 文件夹。

触发管道时，将启动一个作业，该作业使用无人值守机器人运行关联的管道流程。

先决条件

• 机器人版本：
  • 2021.10 和 2022.4： .NET Desktop Runtime 6.0.* 必须在机器人计算机上手动安装。
  • 2022.8 及更高版本： .NET Desktop Runtime 将随机器人自动安装。
• 流程特殊性：
  • 必须将管道流程配置为作为后台流程运行。 这是通过 Studio 中的项目设置菜单完成的。 了解有关 后台流程的更多信息。
  • 将管道流程从 Studio 发布到 Orchestrator 时，请确保同时从“ 发布选项 ” 部分选择“包括源”。 阅读有关 发布自动化项目的更多信息。

配置

Automation Ops™ - 管道通过使用无人值守机器人运行管道流程来工作，这意味着需要在使用它们之前在 Orchestrator 中进行特定配置。 此配置称为管道运行时环境。

Orchestrator 基本配置有一个专用文件夹，其中包含管道流程和机器人帐户，以及用于运行管道作业的计算机或计算机模板。

重要提示：

在快速设置期间创建的机器人帐户至关重要。 所有管道 (Orchestrator 作业) 均代表其运行。 删除机器人帐户会导致管道运行时配置无效，并且需要重新运行快速设置。

在 Orchestrator 中删除专用管道文件夹将中断与其关联的所有管道。

初始设置

首次设置 Automation Ops™ - 管道时，系统会显示一个快速设置窗口，允许您选择租户以及要用于未来运行管道的计算机类型。 您可以选择使用环境中的现有计算机，也可以自动创建一台名为“管道机器人”的新无服务器计算机。

备注：

如果选择创建新的 Serverless 计算机，请确保租户上有足够的 Robot Units 可用。

作为快速设置体验的一部分，系统将自动创建一个名为“管道”的新文件夹和以下角色：

• 管道租户角色
• 管道文件夹角色

管道机器人会自动分配以下角色：

• 租户: 管道租户角色、Allow to be Automation User、Allow to be Automation Publisher
• 管道文件夹：管道文件夹角色、Automation User、Automation Publisher

备注：

确保为管道创建的机器人帐户也分配给目标 Orchestrator 文件夹。 这是必需的，因为管道在该帐户下运行。 有关详细信息，请参阅配置帐户的访问权限。

“运行测试”活动在提供的 Orchestrator 文件夹中运行测试。 管道机器人帐户在相应的文件夹中发布包，但测试可以由该文件夹中符合测试运行条件的任何机器人帐户运行，而不仅仅是管道机器人帐户。

此外，默认情况下可以使用以下预定义的管道流程：

Build.and.publish	克隆 -> 分析 -> 构建 -> 发布
Copy.package.between.environments	下载包 -> 发布包
Update.process.from.code	克隆 -> 分析 -> 构建 -> 发布包 -> 更新流程
Update.with.tests	克隆 -> 分析 -> 运行测试 -> 构建 -> 发布包 -> 更新流程
Build.and.promote.with.approval	克隆 -> 分析 -> 运行测试 -> 构建 -> 发布包 -> 更新流程 -> 批准 -> 下载包 -> 上传包 -> 更新流程

这些默认管道流程带有自己的参数集，例如， Build.and.promote.with.approval 具有以下参数：

• 跳过测试 - 允许您选择是否在管道期间执行测试用例。
• “测试文件夹 ”- 在其中执行测试的 Orchestrator 文件夹。
• “分析策略”-监管 策略，用于保存管道流程中使用的工作流分析器规则。 如果留空，则跳过项目分析。
• 跳过 验证 - 允许您在构建包之前跳过验证。 默认情况下，此值处于禁用状态。
• 批准 人 - 在 Action Center 中创建的任务的批准人的电子邮件地址。
• “FirstOrchestratorUrl ” - 将已构建的包发布到的 Orchestrator 的 URL。
• 第一个Orchestrator 文件夹 - 将构建的包发布到的 Orchestrator 文件夹。
• “SecondOrchestratorUrl ” - 所构建包在获得批准后发布到的 Orchestrator 的 URL。
• “第二个 Orchestrator 文件夹”- Orchestrator 文件夹，在批准后发布所构建的包。
• “拥有相同的包订阅源 ” - 默认情况下，此字段设置为“False”。 如果第一个环境和第二个环境使用相同的包/库订阅源，请将其设置为“True”。
• “流程 名称”- 要更新的流程的名称。 仅在项目为流程时使用。

您还可以使用 Uipath Studio 和 Studio Web 中提供的模板（“模板” 选项卡）开始使用管道。

您可以使用以下模板：

• Build and promote with approval pipeline:

  • 用途：管理自动化项目从开始到批准的整个流程。

  • 步骤: 克隆、分析、运行测试、构建、发布包、更新流程、批准、下载包、上传包和更新包。

• Update process from a code line:

  • 用法：突出显示简化的程序，用于更新和修改正在进行的流程。

  • 步骤: 克隆、分析、构建、发布包和更新流程。

重要提示：

在初始设置中创建的 Cloud Serverless Robot 为标准尺寸。 使用“运行测试”活动时，如果该活动涉及带有 Cloud Serverless 机器人的 Orchestrator 文件夹，请确保机器人为标准大小。

使用“构建”活动时，请验证正在构建的自动化项目与运行该流程的计算机之间的兼容性要求。

例如，使用Windows-Legacy or Windows兼容性创建的项目无法在Cloud Serverless Robot 上构建。 您必须改用基于Windows的计算机。

在运行使用 Integration Service 连接生成和发布流程的管道时，请确保将所有必要的项目文件夹提交给来源控件提供程序。 例如，从 Studio 初始化 git 时，必须提交所有关联的项目文件夹，例如.settings 、 .project和.tmh 。

创建第一个管道

在 Orchestrator 设置完成后，您必须配置 Automation Ops™-Pipelines、保存代码的 GitHub 存储库与 Orchestrator 管道运行时环境之间的初始集成。 执行此集成时，您还将创建第一个管道。

请执行以下步骤：

1. 在 Automation Cloud™ 中，从左侧导航栏中导航到“ Automation Ops™ ” >“管道”。
2. 选择“新建管道” 。 如果您已将外部存储库连接到“来源控件”，则也会自动将其连接到此处。
   注意：只有一个 UiPath™ Automation Cloud™ 组织可以同时连接到 GitHub 组织。
3. 在“位置” 选项卡中，选择外部存储库组织、存储库、分支和自动化项目（可选）。 单击“下一步” 。
   
   
   
   
4. 在“ 管道定义 ” 选项卡中：
   • 选择管道流程。 如果管道流程包含参数，则可以将其值相加。
   
   
   
   
   
5. 在“ 保存并运行” 选项卡中，配置以下内容：
   • 项目名称- 输入管道项目的名称。 默认情况下，名称由存储库的名称和管道自动化项目的名称组成。
   • 说明-（可选）添加说明。
   • 运行此管道 - 选择管道的运行方式：
     • 每次提交- 每当所选项目的存储库中的代码发生更改时，都会触发管道自动化。
     • “我将手动运行”- 手动 触发管道自动化。
       备注：

       在手动触发的管道上，启动作业时使用的提交是所选project.json文件的文件夹中的最新提交。

       如果该提交中该文件夹中没有任何文件发生更改，则该提交不是整个存储库中的最新提交。

6. 单击“ 保存 ” 以保存管道，或单击“ 保存并运行 ” 以保存并运行管道。

重要提示：

如果在步骤 1 中未选择存储库中的特定流程 （未选择任何自动化项目） ，并且管道设置为由提交触发，则管道将由存储库中的任何提交触发。

ProjectPath 参数将填充在管道配置的“ 位置 ”步骤中的 Automation project (optional) 字段中选择的值。

如果该字段留空，则 ProjectPath 流程参数留空。 此场景可用于只有一个自动化项目的存储库。

手动运行管道

1. 在 Automation Cloud™ 中，从左侧导航栏中导航到Automation Ops™ 。
2. 选择“管道” 。 系统将显示可用的管道。
3. 选择一个管道，然后选择“ 启动新作业”。 这将触发管道运行，并且您可以实时查看每个步骤的进度。

在这里，您还可以通过选择“管道设置” 来编辑管道。 这将显示管道摘要，您可以从中执行以下操作：

• 编辑管道- 选择以更新管道。 您只能更新管道名称、说明、触发器类型和自定义管道参数。 无法更改位置和管道定义。

• 删除管道- 选择以删除管道（与管道相关的所有信息将被删除）。

预定义的管道流程

默认情况下，以下预定义管道流程可用：

Build.and.publish	克隆 -> 分析 -> 构建 -> 发布
Copy.package.between.environments	下载包 -> 发布包
Update.process.from.code	克隆 -> 分析 -> 构建 -> 发布包 -> 更新流程
Update.with.tests	克隆 -> 分析 -> 运行测试 -> 构建 -> 发布包 -> 更新流程
Build.and.promote.with.approval	克隆 -> 分析 -> 运行测试 -> 构建 -> 发布包 -> 更新流程 -> 批准 -> 下载包 -> 上传包 -> 更新流程

这些默认管道流程带有以下参数集：

• 构建并升级 （含批准）流程：
  • “流程 名称”- 要更新的流程的名称。 仅在项目为流程时使用。
  • 批准 人 - 在 Action Center 中创建的任务的批准人的电子邮件地址。
  • 跳过测试 - 允许您选择是否在管道期间执行测试用例。
  • “分析策略”-监管 策略，用于保存管道流程中使用的工作流分析器规则。 如果留空，则跳过项目分析。
  • 跳过 验证 - 允许您在构建包之前跳过验证。 默认情况下，此值处于禁用状态。
  • 第一个Orchestrator 文件夹 - 将构建的包发布到的 Orchestrator 文件夹。
  • “FirstOrchestratorUrl ” - 将已构建的包发布到的 Orchestrator 的 URL。
  • “第二个 Orchestrator 文件夹”- Orchestrator 文件夹，在批准后发布所构建的包。
  • “SecondOrchestratorUrl ” - 所构建包在获得批准后发布到的 Orchestrator 的 URL。
  • “测试文件夹 ”- 在其中执行测试的 Orchestrator 文件夹。
  • “拥有相同的包订阅源 ” - 默认情况下，此字段设置为“False”。 如果第一个环境和第二个环境使用相同的包/库订阅源，请将其设置为“True”。
• Build.and.publish
  • “分析策略”-监管 策略，用于保存管道流程中使用的工作流分析器规则。 如果留空，则跳过项目分析。
  • 跳过 验证 - 允许您在构建包之前跳过验证。 默认情况下，此值处于禁用状态。
  • “Orchestrator URL” - 将构建的包发布到的 Orchestrator URL。
  • Orchestrator 文件夹 - 将构建的包发布到的 Orchestrator 文件夹。
• Copy.package.between.environments
  • 包名称 - 要复制的包的名称。
  • “是库 ” - 定义包是否为库。
  • “包 版本”- 要复制的包的版本。
  • “源 Orchestrator 文件夹”- 从中复制包的 Orchestrator 文件夹。
  • “源 Orchestrator URL” - 从中复制包的 Orchestrator 的 URL。
  • “目标 Orchestrator URL” - 将包复制到的 Orchestrator 的 URL。
  • “目标 Orchestrator 文件夹”- 将包复制到的 Orchestrator 文件夹。
• Update.process.from.code
  • “流程名称”- 要更新的流程的名称。 仅在项目为流程时使用。
  • “分析策略”-监管 策略，用于保存管道流程中使用的工作流分析器规则。 如果留空，则跳过项目分析。
  • 跳过 验证 - 允许您在构建包之前跳过验证。 默认情况下，此值处于禁用状态。
  • Orchestrator URL - 要更新的包所在 Orchestrator 的 URL。
  • “Orchestrator 文件夹” - 要更新的包所在的 Orchestrator 文件夹。
• Update.with.tests
  • “流程名称”- 要更新的流程的名称。 仅在项目为流程时使用。
  • “分析策略”-监管 策略，用于保存管道流程中使用的工作流分析器规则。 如果留空，则跳过项目分析。
  • 跳过 测试 - 允许您在构建包之前跳过测试。 默认情况下，此值处于禁用状态。
  • Orchestrator URL - 要更新的包所在 Orchestrator 的 URL。
  • “Orchestrator 文件夹” - 要更新的包所在的 Orchestrator 文件夹。
  • “Orchestrator 测试文件夹”- 管道中使用的测试所在的 Orchestrator 文件夹。

备注：

您打算构建的自动化项目与运行管道流程的计算机之间存在兼容性要求。

正确的映射为：

• Windows - 旧版项目 → 构建操作系统：仅限 Windows
• Windows 项目 → 构建操作系统：仅限 Windows
• 跨平台项目 → 构建操作系统：Windows 或 Linux

默认管道流程参数

Automation Ops™ 为管道流程提供以下默认参数集：

名称	方向	参数类型	描述
内部版本编号	输入	字符串	每次管道作业运行的唯一编号。
存储库 URL	输入	字符串	存储库的 URL。 通常由“克隆”活动使用。
提交 SHA	输入	字符串	提交标识符。
项目路径	输入	字符串	project.json 文件的路径。 适用于“构建”活动。
提交者用户名	输入	字符串	触发提交的人员的用户名。
RepositoryType	输入	字符串	存储库类型（例如 git）。
RepositoryBranch	输入	字符串	使用的存储库分支。

查看管道日志

每次运行管道时都会生成日志。 您可以在 Automation Ops™ 中查看日志，并且由于每次管道运行都会在 Orchestrator 中创建一个作业，因此您还可以在 Orchestrator 中查看这些日志：

• 在 Automation Ops™ 中，将鼠标指针悬停在管道右侧，然后从上下文菜单中选择“查看日志” 。

• 在 Orchestrator 中，访问“专用管道”文件夹 >“ 自动化 ” > “作业”。 在“ 来源 ” 列中，查找“ 管道 ” 标签，然后选择 “查看日志”。

手动删除 Webhook

如果将管道设置为在创建期间每次提交时运行，则系统会在 GitHub/Azure DevOps 中自动创建 Webhook。

删除运行时配置后，如果已删除源代码控件与管道的链接，则应手动删除 Webhook。 虽然不删除它们不会影响 CI/CD 服务的功能，但我们建议执行此步骤。

对于在提交时具有触发器并且来源控件连接已删除的每个管道，您必须访问 GitHub/Azure DevOps 存储库，并在删除运行时环境后删除 Webhook。

重要提示：

如果已在您的组织中删除来源控件连接，并且该存储库当前已连接到另一个 UiPath 组织，则您可以从第二个组织中删除有效的 Webhook。 不得删除这些管道，否则将不会在提交时触发管道。

因此，在删除 Webhook 之前，请确保当前存储库在 UiPath 组织的有效 CI/CD 运行时配置中没有有效连接。

从 GitHub 存储库中删除 Webhook

要从 GitHub 存储库中删除 Webhook，请执行以下操作：

1. 转到 GitHub 存储库，然后选择“设置” >“ Webhooks ”。
   
2. 删除所有以/roboticsops_/cicd_/api/webhooks/github/pipeline结尾的 Webhook URL。
   

从 Azure DevOps 存储库中删除 Webhook

要从 Azure DevOps 存储库中删除 Webhook，请执行以下操作：

1. 转到 Azure DevOps 存储库，然后选择“项目设置” > “服务挂钩”。
2. 在要删除的 Webhook 上，选择“编辑” 。
   
3. 确保 Webhook URL 以/roboticsops_/cicd_/api/webhooks/azure/pipeline结尾。
   
   
4. 删除 Webhook URL。