Git 导出/恢复

Dialogflow CX 可与多个 Git 提供商（GitHub、Gitlab、Bitbucket 等）集成。通过此集成，您可以轻松地将代理导出为 JSON 以推送到 Git 提供商，并从 Git 提供商拉取以恢复代理。推送到 Git 提供商的 JSON 导出格式是导出代理的展开 zip 文件内容。

使用此功能可让您利用 Git 提供方的源代码控制功能，例如：

  • 使用代码审核工具审核代理变更
  • 使用差异工具检查代理差异
  • 合并

限制

存在以下限制：

  • [仅限旧版集成] GitHub API 对可在单个提交中更新的文件数量有限制。如果文件数量超过 500，您可能无法从 Dialogflow CX 推送到 GitHub。在这种情况下，您可以将代理导出为 ZIP 文件，并在机器上使用 Git CLI 将代理文件推送到 GitHub。此限制将在后续 Dialogflow CX 版本中得到解决。
  • 不支持 GitHub 私有访问自托管代码库，因为 Dialogflow CX 无法访问这些代码库。
  • Git 代码库不能包含代理导出功能导出的代理文件以外的任何文件。代码库中的任何其他文件都会在每次推送时移除。

配置

如需配置此功能，您需要从 Git 提供商处获取访问令牌，将其存储在 Secret Manager 中，然后向 Dialogflow CX 提供 Secret 资源：

访问令牌

如需从 Git 提供商处获取访问令牌，请执行以下操作：

GitHub

您需要获取 GitHub 个人令牌。如果您使用精细的个人访问令牌，则需要以下权限访问权限：

  • 代码库权限 > 内容：读取和写入
  • 代码库权限 > 元数据：只读（选择“内容”权限后，系统应会自动选择此权限）

GitLab

您需要获取 GitLab 个人访问令牌。

Bitbucket

您需要获取 Bitbucket 访问令牌。

Secret Manager

现在，您已拥有访问令牌，接下来需要为令牌创建 Secret：

  1. 启用 Secret Manager API。
  2. 创建 Secret。

Dialogflow CX 配置

如需为 Dialogflow CX 配置此集成，请执行以下操作：

  1. 为 Dialogflow 服务代理授予访问 Secret Manager 中的访问令牌 Secret 的权限。 为代理项目中的 gcp-sa-dialogflow.iam.gserviceaccount.com 服务账号提供 Secret Manager Secret Accessor 角色。 请参阅授予对 Secret Manager 密钥的访问权限。
  2. 打开 Git 集成配置：
    • 对话智能体控制台
      1. 点击右上角附近的“设置”图标，打开设置显示屏。
      2. 向下滚动，然后点击 Add Git integration（添加 Git 集成）。
    • Dialogflow CX 控制台
      1. 点击管理标签页。
      2. 在测试和部署部分中，点击 Git。
      3. 点击新建 (Create new)。
  3. 提供配置详细信息：
    1. 输入以下内容：
      • GitHub 连接的显示名。
      • Git 代码库网址（例如：https://github.com/<path-to-repo>.git）。
      • 添加代理将与之互动的 Git 分支。 您可以点击分支旁边的星形图标，将相应分支指定为默认分支。
      • 访问令牌 Secret，即您创建的密文版本，格式为 projects/*/secrets/*/versions/*（针对特定版本）或 projects/*/secrets/*/versions/latest（针对最新版本）。
    2. 点击连接。
    3. Git 服务可能需要一分钟才能准备就绪。 控制台会显示通知。

推送和恢复

配置完成后，您可以将代理推送到 Git 或从 Git 拉取代理。

推送按钮用于导出代理，并向 Git 分支下拉菜单中选择的 Git 分支提交。此提交将包含整个代理，而不是特定更改，并且会删除代码库中的所有现有文件。

具有 Dialogflow Reader 角色的用户能够推送到 Git 代码库。为防止不必要的推送，请使用只读个人访问令牌配置这些代理。

恢复按钮用于从 Git 分支下拉菜单中选择的 Git 分支拉取代理数据，并根据此数据恢复 Dialogflow CX 代理。这会覆盖您的代理，与任何代理恢复操作的行为方式相同。

用例示例

以下示例展示了多人如何使用此功能向生产代理提出不同的代理更改建议。

假设您的代理使用以下 Git 分支：

  • Prod：生产代理的分支
  • Dev1：用于代理开发的 branch
  • Dev2：用于代理开发的另一个分支

用户 1 想要提议更改代理，并执行以下步骤：

  1. 将生产代理导出到新代理。
  2. 根据需要对此代理副本进行更改。
  3. 测试更改。
  4. 将更改后的代理推送到 Dev1 分支。
  5. 创建针对 Prod 分支的合并请求。

用户 2 想要提议更改代理，并执行以下步骤：

  1. 将生产代理导出到新代理。
  2. 根据需要对此代理副本进行更改。
  3. 测试更改。
  4. 将更改后的代理推送到 Dev2 分支。
  5. 创建针对 Prod 分支的合并请求。

用户 3 查看来自两位用户的合并请求，并执行以下步骤：

  1. 解决冲突。
  2. 提交已获批准的更改。
  3. 将生产 Git 分支恢复到生产 Dialogflow CX 代理。
上一页
会话数
下一页
情感