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 Secret 的访问权限。
  2. 打开 Git 集成配置：
    • 对话智能体控制台
      1. 点击右上角附近的设置图标，打开设置显示界面。
      2. 向下滚动并点击添加 Git 集成 。
    • Dialogflow CX 控制台
      1. 点击管理 标签页。
      2. 在测试和部署 部分中，点击 Git 。
      3. 点击新建 。
  3. 提供配置详细信息：
    1. 输入以下内容：
      • GitHub 连接的显示名。
      • Git 代码库网址（例如： https://github.com/<path-to-repo>.git）。
      • 添加代理将与之交互的 Git 分支。 您可以点击分支旁边的星形图标，将分支指定为默认分支。
      • 访问令牌 Secret，即您创建的 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：代理开发的分支
  • Dev2：代理开发的另一个分支

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

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

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

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

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

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