Automation Ops
最新
False
横幅背景图像
Automation Ops 用户指南
上次更新日期 2024年4月26日

UiPath Automation Ops - 管道

Automation Ops - 管道提供了一种设置持续集成/持续交付系统的简单方法,该方法可管理外部存储库(例如 Github 或 Azure DevOps)中的自动化项目代码。

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

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

先决条件

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

配置

Automation Ops - 管道通过使用 Unattended Robot运行管道流程来工作,这意味着在使用之前需要在 Orchestrator 中进行特定配置。 此配置称为 管道 Runtime 环境

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

重要提示:

The robot account created during the quick setup is essential. All the pipelines (Orchestrator jobs) are ran on its behalf. Deleting the robot account causes an invalid pipeline runtime configuration and the need to rerun the quick setup.

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

初始设置

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

备注:

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

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

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

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

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

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

The Run Tests activity runs the tests in the provided Orchestrator folder. The Pipelines robot account publishes the package in the respective folder, but the tests can be run by any robot account in that folder that qualifies for the test run, not only by the Pipelines robot account.

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

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”。
  • 流程 名称”- 要更新的流程的名称。 仅在项目为流程时使用。
重要提示:

When using the Build activity, validate the compatibility requirements between the automation projects you are building and the machine running the process.

例如,使用Windows-Legacy or Windows兼容性创建的项目无法在Cloud Serverless Robot 上构建。 您必须改用基于Windows的计算机。
在运行使用 Integration Service 连接生成和发布流程的管道时,请确保将所有必要的项目文件夹提交给来源控件提供程序。 例如,从 Studio 初始化 git 时,必须提交所有关联的项目文件夹,例如.settings.project.tmh

创建第一个管道

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

请执行以下步骤:

  1. 在 Automation Cloud 中,从左侧导航栏中导航到“ Automation Ops ” >“管道”。
  2. 选择“新建管道” 。 如果您已将外部存储库连接到“来源控件”,则也会自动将其连接到此处。
    注意: 一次只能将一个 UiPath Automation Cloud 组织连接到 GitHub 组织。
  3. 在“位置” 选项卡中,选择外部存储库组织、存储库、分支和自动化项目(可选)。 单击“下一步”

  4. 在“ 管道定义 ” 选项卡中:
    • 选择管道流程。 如果管道流程包含参数,则可以将其值相加。


  5. 在“ 保存并运行” 选项卡中,配置以下内容:
    • 项目名称- 输入管道项目的名称。 默认情况下,名称由存储库的名称和管道自动化项目的名称组成。
    • 说明-(可选)添加说明。
    • 运行此管道 - 选择管道的运行方式:
      • 每次提交- 每当所选项目的存储库中的代码发生更改时,都会触发管道自动化。
      • “我将手动运行”- 手动 触发管道自动化。
  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 运行时配置中没有有效连接。

docs image

从 GitHub 存储库中删除 Webhook

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

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

从 Azure DevOps 存储库中删除 Webhook

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

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

此页面是否有帮助?

获取您需要的帮助
了解 RPA - 自动化课程
UiPath Community 论坛
Uipath 白色徽标
信任与安全
© 2005-2024 UiPath. All rights reserved.