配置服务台

默认情况下，新项目会启用服务台功能。
如果未启用，您可以在项目设置中手动开启。

前置条件：

• 您必须拥有项目的 维护者 角色。
• 在 GitLab 自托管版中，您必须为 GitLab 实例 配置接收邮件。
  建议使用 邮件子地址，
  也可使用 通配邮箱。
  此操作需要管理员权限。
• 您必须已为项目启用 问题 追踪器。

在项目中启用服务台：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 开启 启用服务台 开关。
5. （可选）填写以下字段：
   • 为服务台邮件地址 添加后缀。
   • 如果 附加到所有服务台问题的模板 列表为空，请在仓库中创建 描述模板。
6. 选择 保存更改。

服务台现已为该项目启用。
当有人向 服务台邮件地址 发送邮件时，GitLab 会创建一个包含邮件内容的保密问题。

服务台术语表

本术语表提供与服务台相关的定义。

提升项目安全性

为提升服务台项目的安全性，建议您：

• 在邮件系统中为服务台邮件地址设置别名，以便后续修改。
• 在 GitLab 实例中 启用 Akismet 为服务台添加垃圾邮件检测。
  未被拦截的垃圾邮件可能导致大量垃圾工单创建。

自定义发送给外部参与者的邮件

以下情况会向外部参与者发送邮件：

• 请求者通过邮件向服务台提交新工单。
• 外部参与者被添加到服务台工单。
• 服务台工单新增公开评论（编辑评论不会触发新邮件）。

您可以使用服务台邮件模板自定义邮件正文。模板可包含 GitLab 风格 Markdown 和 部分 HTML 标签。
例如，可根据企业品牌规范格式化邮件的页眉页脚，也可使用以下占位符显示服务台工单或 GitLab 实例的动态内容。

感谢邮件

当请求者通过服务台提交问题时，GitLab 会发送 感谢邮件。
未额外配置时，GitLab 发送默认感谢邮件。

创建自定义感谢邮件模板：

1. 在仓库的 .gitlab/service_desk_templates/ 目录中创建文件 thank_you.md。
2. 填充 Markdown 文件，包含文本、GitLab 风格 Markdown、部分 HTML 标签 和占位符，以自定义对服务台请求者的回复。

新参与者邮件

当 外部参与者 被添加到工单时，GitLab 发送 新参与者邮件 通知其加入对话。
未额外配置时，GitLab 发送默认新参与者邮件。

创建自定义新参与者邮件模板：

1. 在仓库的 .gitlab/service_desk_templates/ 目录中创建文件 new_participant.md。
2. 填充 Markdown 文件，包含文本、GitLab 风格 Markdown、部分 HTML 标签 和占位符，以自定义对服务台请求者的回复。

新评论邮件

当服务台工单新增公开评论时，GitLab 发送 新评论邮件。
未额外配置时，GitLab 发送评论内容。

创建自定义新评论邮件模板：

1. 在仓库的 .gitlab/service_desk_templates/ 目录中创建文件 new_note.md。
2. 填充 Markdown 文件，包含文本、GitLab 风格 Markdown、部分 HTML 标签 和占位符，以自定义新评论邮件。
   务必包含 %{NOTE_TEXT} 确保收件人可查看评论内容。

实例级邮件页眉、页脚和附加文本

实例管理员可为 GitLab 实例添加页眉、页脚或附加文本，并应用于所有 GitLab 发送的邮件。
若使用自定义 thank_you.md、new_participant 或 new_note.md，请在模板中添加 %{SYSTEM_HEADER}、%{SYSTEM_FOOTER} 或 %{ADDITIONAL_TEXT} 以包含此内容。

更多信息请参阅 系统页眉页脚消息 和 自定义附加文本。

为服务台工单使用自定义模板

您可为每个项目选择一个 描述模板
附加到每个新服务台工单的描述中。

您可在多个层级设置描述模板：

• 整个 实例。
• 特定 群组或子群组。
• 特定 项目。

模板具有继承性。例如，在项目中可访问实例或项目父群组设置的模板。

前置条件：

• 您必须已 创建描述模板。

使用自定义描述模板：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 从 附加到所有服务台问题的模板 下拉列表中搜索或选择您的模板。

支持机器人用户

服务台通过特殊的支持机器人用户创建问题。
该用户不计入 计费用户 范围，因此不占用许可证数量。

在 GitLab 16.0 及更早版本中，来自服务台邮件的评论显示 GitLab Support Bot 作为作者。
在 GitLab 16.1 及更高版本 中，这些评论显示发送邮件的用户邮箱。
此功能仅适用于 GitLab 16.1 及更高版本创建的评论。

修改支持机器人的显示名称

您可以修改支持机器人的显示名称。服务台发送的邮件在 From 头部使用此名称。
默认显示名称为 GitLab Support Bot。

编辑自定义邮件显示名称：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 在 邮件显示名称 下方输入新名称。
5. 选择 保存更改。

默认工单可见性

新工单默认保密，仅拥有 规划者 角色及以上的项目成员可查看。

在私有和内部项目中，您可以配置 GitLab 使新工单默认不保密，任何项目成员均可查看。

在公开项目中，此设置不可用，因为新工单始终默认保密。

前置条件：

• 您必须拥有项目的 维护者 角色。

禁用此设置：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 取消勾选 新工单默认保密 复选框。
5. 选择 保存更改。

外部参与者评论时重新打开问题

您可以配置 GitLab 在外部参与者通过邮件为问题添加新评论时重新打开已关闭的问题。
此操作还会添加内部评论并提及问题指派人，同时为其创建待办事项。

操作演示请观看 简短展示视频。

前置条件：

• 您必须拥有项目的 维护者 角色。

启用此设置：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 勾选 外部参与者新评论时重新打开问题 复选框。
5. 选择 保存更改。

自定义邮件地址

配置自定义邮件地址作为支持通信的发件人，通过用户熟悉的域名维护品牌形象并增强请求者信任。

功能概述请观看 简短展示视频。

此功能处于 Beta 阶段。
Beta 功能尚未完全就绪，但在正式发布前不太可能发生重大变更。我们鼓励用户试用 Beta 功能并在 反馈问题 中提供反馈。

前置条件

每个项目可使用一个自定义服务台邮件地址，且在实例内必须唯一。

自定义邮件地址需满足以下所有要求：

• 可设置邮件转发。

• 转发邮件保留原始 From 头部。

• 服务提供商必须支持子地址。邮件地址由本地部分（@ 前内容）和域名部分组成。

  通过邮件子地址，可在本地部分添加 + 符号后跟任意文本创建唯一变体。
  例如邮件地址 [email protected]，发送至 [email protected] 检查是否支持子地址。
  该邮件应出现在您的收件箱中。

• 您拥有 SMTP 凭据（建议使用应用密码）。
  用户名和密码使用 AES 256 位密钥加密存储在数据库中。

• SMTP 主机 必须可从 GitLab 实例网络（自托管版）或公共互联网（GitLab.com）解析。

• 您必须拥有项目的 维护者 角色。

• 项目必须已配置服务台。

配置自定义邮件地址

当您希望使用自己的邮件地址发送服务台邮件时，请配置并验证自定义邮件地址。

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台 并找到 配置自定义邮件地址 部分。
4. 记录当前项目的服务台地址，并在您的邮件提供商（如 Gmail）中设置从自定义邮件地址到服务台地址的转发。
5. 返回 GitLab，填写字段。
6. 选择 保存并测试连接。

配置已保存，并触发自定义邮件地址验证。

验证流程

1. 完成配置后，所有项目所有者和保存自定义邮件配置的管理员将收到通知邮件。

2. 使用提供的 SMTP 凭据向自定义邮件地址（含子地址部分）发送验证邮件。
   邮件包含验证令牌。当邮件转发设置正确且满足所有前置条件时，邮件将被转发到您的服务台地址并由 GitLab 接收。GitLab 检查以下条件：

   1. GitLab 可使用 SMTP 凭据发送邮件。
   2. 支持子地址（使用 +verify 子地址部分）。
   3. 转发后 From 头部保留。
   4. 验证令牌正确。
   5. 邮件在 30 分钟内接收。

   通常仅需几分钟。

随时可取消验证或验证失败时，选择 重置自定义邮件。
设置页面将更新并反映当前验证状态。SMTP 凭据将被删除，您可以重新开始配置。

验证失败和成功时，所有项目所有者和触发验证流程的用户将收到包含验证结果的通知邮件。
若验证失败，邮件还包含失败原因详情。

若验证成功，自定义邮件地址即可使用。
现在可启用使用自定义邮件地址发送服务台邮件。

配置故障排查

配置自定义邮件时可能遇到以下问题。

无效凭据

您可能收到错误提示：使用了无效凭据。

当 SMTP 服务器返回认证失败时会发生此问题。

排查方法：

1. 检查 SMTP 凭据，特别是用户名和密码。
2. 有时 GitLab 无法自动选择 SMTP 服务器支持的认证方法。请尝试：

   • 可用认证方法（Plain、Login 和 CRAM-MD5）。

   • 使用 swaks 命令行工具 检查 SMTP 服务器支持的认证方法：

     1. 使用您的凭据运行以下命令，查找以 250-AUTH 开头的行：

        swaks --to [email protected] \
              --from [email protected] \
              --auth-user [email protected] \
              --server [email protected]:587 \
              -tls-optional \
              --auth-password your-app-password

     2. 在自定义邮件设置表单中选择支持的认证方法之一。

错误的转发目标

您可能收到错误提示：使用了错误的转发目标。

当验证邮件被转发到自定义邮件配置表单中显示的项目特定服务台地址以外的地址时会发生此问题。

您必须使用从 incoming_email 生成的服务台地址。
不支持转发到 service_desk_email 生成的附加服务台别名地址，因其不支持所有邮件回复功能。

排查方法：

1. 找到正确的转发目标地址。可通过以下方式之一：
   • 记录所有项目所有者和触发验证流程用户收到的验证结果邮件中的地址。
   • 复制自定义邮件设置表单中的 服务台邮件地址 输入框中的地址。
2. 将所有邮件转发到自定义邮件地址的正确目标地址。

启用或禁用自定义邮件地址

自定义邮件地址验证后，管理员可启用或禁用使用自定义邮件地址发送服务台邮件。

启用自定义邮件地址：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 开启 启用自定义邮件 开关。
   服务台邮件将使用 SMTP 凭据发送给外部参与者。

禁用自定义邮件地址：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 关闭 启用自定义邮件 开关。
   由于您设置了邮件转发，发送到自定义邮件地址的邮件仍会被处理并显示为项目中的服务台工单。
   服务台邮件现在使用 GitLab 实例的默认出站邮件配置发送给外部参与者。

修改或移除自定义邮件配置

若要修改自定义邮件配置，必须重置并移除配置，然后重新配置自定义邮件。

随时可重置配置，选择 重置自定义邮件。
凭据将从数据库中删除。

自定义邮件回复地址

外部参与者可通过 邮件回复 服务台工单。
GitLab 使用包含 32 字符回复键的邮件回复地址，对应工单。
配置自定义邮件时，GitLab 从该邮件生成回复地址。

使用自有域名的 Google Workspace

使用自有域名的 Google Workspace 时，为服务台配置自定义邮件地址。

前置条件：

• 您已有 Google Workspace 账户。
• 可为租户创建新账户。

配置自定义服务台邮件地址：

1. 配置 Google Workspace 账户。
2. 在 Google Workspace 中配置邮件转发。
3. 使用 Google Workspace 账户配置自定义邮件地址。

配置 Google Workspace 账户

首先，您必须创建并配置 Google Workspace 账户。

在 Google Workspace 中：

1. 为要使用的自定义邮件地址创建新账户（例如 [email protected]）。
2. 登录该账户并启用 双因素认证。
3. 创建应用密码 作为 SMTP 密码。
   安全存储并移除字符间的空格。

接下来，您必须 在 Google Workspace 中配置邮件转发。

在 Google Workspace 中配置邮件转发

以下步骤需在 GitLab 和 Google Workspace 之间切换。

在 GitLab 中：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 记录 服务台邮件地址 下方的地址。

在 Google Workspace 中：

1. 登录自定义邮件账户并打开 转发和 POP/IMAP 设置页面。
2. 选择 添加转发地址。
3. 输入自定义邮件表单中的服务台地址。
4. 选择 下一步。
5. 确认输入并选择 继续。Google 向服务台地址发送邮件并要求确认码。

在 GitLab 中：

1. 转到项目的 问题 页面，等待从 Google 的确认邮件创建新问题。
2. 打开问题并记录确认码。
3. （可选）删除该问题。

在 Google Workspace 中：

1. 输入确认码并选择 验证。
2. 选择 转发邮件副本至 并确保从下拉列表中选择服务台地址。
3. 在页面底部选择 保存更改。

接下来，使用 Google Workspace 账户配置自定义邮件地址 以用于服务台。

使用 Google Workspace 账户配置自定义邮件地址

在 GitLab 中：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台 并找到自定义邮件设置。
4. 填写字段：
   • 自定义邮件地址：您的自定义邮件地址。
   • SMTP 主机：smtp.gmail.com。
   • SMTP 端口：587。
   • SMTP 用户名：自动填充自定义邮件地址。
   • SMTP 密码：之前为自定义邮件账户创建的应用密码。
   • SMTP 认证方法：让 GitLab 选择服务器支持的方法（推荐）。
5. 选择 保存并测试连接。
6. 完成 验证流程 后，您应能 启用自定义邮件地址。

使用自有域名的 Microsoft 365 (Exchange Online)

使用自有域名的 Microsoft 365 (Exchange) 时，为服务台配置自定义邮件地址。

前置条件：

• 您已有 Microsoft 365 账户。
• 可为租户创建新账户。

配置自定义服务台邮件地址：

1. 配置 Microsoft 365 账户。
2. 在 Microsoft 365 中配置邮件转发。
3. 使用 Microsoft 365 账户配置自定义邮件地址。

配置 Microsoft 365 账户

首先，您必须创建并配置 Microsoft 365 账户。
本指南中，使用许可用户作为自定义邮箱。也可尝试其他配置选项。

在 Microsoft 365 管理中心 中：

1. 为要使用的自定义邮件地址创建新账户（例如 [email protected]）。
   1. 展开 用户 部分，从菜单中选择 活跃用户。
   2. 选择 添加用户 并按屏幕说明操作。
2. 在 Microsoft Entra（原名 Active Directory）中为账户启用双因素认证。
3. 允许用户创建应用密码。
4. 为账户启用 经过身份验证的 SMTP。
   1. 从列表中选择账户。
   2. 在抽屉中选择 邮件。
   3. 在 邮件应用 下方选择 管理邮件应用。
   4. 勾选 经过身份验证的 SMTP 并选择 保存更改。
5. 根据您的整体 Exchange Online 配置，可能需要配置以下内容：

   1. 使用 Azure Cloud Shell 允许 SMTP 客户端身份验证：

      Set-TransportConfig -SmtpClientAuthenticationDisabled $false

   2. 使用 Azure Cloud Shell 允许 使用 SMTP AUTH 的传统 TLS 客户端：

      Set-TransportConfig -AllowLegacyTLSClients $true

   3. 若要转发到外部收件人，请参阅如何启用 外部邮件转发 的指南。
      您可能还想 创建出站反垃圾邮件策略 以仅允许需要转发的用户转发到外部收件人。

6. 登录该账户并启用双因素认证。
   1. 从右上角菜单选择 查看账户 并 浏览至 安全信息。
   1. 选择 添加登录方法 并选择适合您的方法（身份验证器应用、电话或邮件）。
   2. 按屏幕说明操作。

7. 在 安全信息 页面，创建应用密码作为 SMTP 密码。

1. 选择 添加登录方法 并从下拉列表中选择 应用密码。

2. 为应用密码设置描述性名称，如 GitLab SD。

3. 选择 下一步。

4. 复制显示的密码并安全存储。

5. 可选。确保您可使用 swaks 命令行工具 通过 SMTP 发送邮件。

6. 使用您的凭据运行以下命令，并将应用密码作为 auth-password：

   swaks --to [email protected] \
         --from [email protected] \
         --auth-user [email protected] \
         --server smtp.office365.com:587 \
         -tls-optional \
         --auth-password <your_app_password>

接下来，您必须 在 Microsoft 365 中配置邮件转发。

在 Microsoft 365 中配置邮件转发

以下步骤需在 GitLab 和 Microsoft 365 管理中心之间切换。

在 GitLab 中：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。

2. 选择 设置 > 常规。

3. 展开 服务台。

4. 记录 服务台邮件地址 下方的地址（不含子地址部分）。

   若收件地址包含子地址（例如 GitLab 生成的回复地址）且转发邮件地址也包含子地址（服务台邮件地址），则邮件不会被转发。

   例如，[email protected] 变为 [email protected]。
   这没问题，因为 Exchange Online 在转发后保留自定义邮件地址在 To 头部，GitLab 可根据自定义邮件地址分配正确的项目。

在 Microsoft 365 管理中心 中：

1. 展开 用户 部分，从菜单中选择 活跃用户。

1. 从列表中选择要用于自定义邮件的账户。
2. 在抽屉中选择 邮件。
3. 在 邮件转发 下方选择 管理邮件转发。
4. 勾选 转发发送到此邮箱的所有邮件。
5. 在 转发邮件地址 中输入自定义邮件表单中的服务台地址（不含子地址部分）。
6. 选择 保存更改。

接下来，使用 Microsoft 365 账户配置自定义邮件地址 以用于服务台。

使用 Microsoft 365 账户配置自定义邮件地址

在 GitLab 中：

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台 并找到自定义邮件设置。
4. 填写字段：
   • 自定义邮件地址：您的自定义邮件地址。
   • SMTP 主机：smtp.office365.com。
   • SMTP 端口：587。
   • SMTP 用户名：自动填充自定义邮件地址。
   • SMTP 密码：之前为自定义邮件账户创建的应用密码。
   • SMTP 认证方法：Login。
5. 选择 保存并测试连接。
6. 完成 验证流程 后，您应能 启用自定义邮件地址。

已知问题

• 某些服务提供商不再允许 SMTP 连接。
  通常可按用户启用并创建应用密码。

使用附加服务台别名邮件

您可为实例使用附加的服务台别名邮件地址。

为此，您必须在实例配置中配置 service_desk_email。
您也可在项目设置中配置 自定义后缀 以替换子地址部分的默认 -issue-。

配置服务台别名邮件

服务台默认使用 接收邮件 配置。
但为拥有独立的服务台邮件地址，请在项目设置中使用 自定义后缀 配置 service_desk_email。

前置条件：

• address 必须在地址的 user 部分包含 +%{key} 占位符（在 @ 前）。
  该占位符用于标识应创建问题的项目。
• service_desk_email 和 incoming_email 配置必须始终使用独立邮箱，以确保服务台邮件正确处理。

使用 IMAP 为服务台配置自定义邮箱：

在配置文件中完整添加以下代码段：

gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@gmail.com"
gitlab_rails['service_desk_email_email'] = "[email protected]"
gitlab_rails['service_desk_email_password'] = "[REDACTED]"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_idle_timeout'] = 60
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_host'] = "imap.gmail.com"
gitlab_rails['service_desk_email_port'] = 993
gitlab_rails['service_desk_email_ssl'] = true
gitlab_rails['service_desk_email_start_tls'] = false

service_desk_email:
  enabled: true
  address: "project_contact+%{key}@example.com"
  user: "[email protected]"
  password: "[REDACTED]"
  host: "imap.gmail.com"
  delivery_method: webhook
  secret_file: .gitlab-mailroom-secret
  port: 993
  ssl: true
  start_tls: false
  log_path: "log/mailroom.log"
  mailbox: "inbox"
  idle_timeout: 60
  expunge_deleted: true

配置选项与配置 接收邮件 相同。

使用加密凭据

您可使用加密文件存储服务台邮件凭据，而非在配置文件中以明文存储。

前置条件：

• 要使用加密凭据，必须先启用 加密配置。

加密文件支持以下配置项：

• user
• password

Microsoft Graph

service_desk_email 可配置为使用 Microsoft Graph API 而非 IMAP 读取 Microsoft Exchange Online 邮箱。
按照 与接收邮件相同的方式 设置 Microsoft Graph 的 OAuth 2.0 应用。

配置服务台别名邮件后缀

您可在项目的服务台设置中设置自定义后缀。

后缀只能包含小写字母（a-z）、数字（0-9）或下划线（_）。

配置后缀后，会创建新的服务台邮件地址，格式为：
service_desk_email_address 设置 + 格式为 <project_full_path>-<custom_suffix> 的键。

前置条件：

• 您必须已配置 服务台别名邮件。

1. 在左侧边栏选择 搜索或跳转 并找到您的项目。
2. 选择 设置 > 常规。
3. 展开 服务台。
4. 在 邮件地址后缀 下方输入要使用的后缀。
5. 选择 保存更改。

例如，假设 mygroup/myproject 项目的服务台设置配置如下：

• 邮件地址后缀设置为 support。
• 服务台邮件地址配置为 contact+%{key}@example.com。

该项目的服务台邮件地址为：[email protected]。
接收邮件 地址仍然有效。

若未配置自定义后缀，则使用默认项目标识符识别项目。

在多节点环境中配置邮件摄取

多节点环境是指为可扩展性、容错性和性能原因，GitLab 在多台服务器上运行的设置。

GitLab 使用名为 mail_room 的独立进程从 incoming_email 和 service_desk_email 邮箱摄取新未读邮件。

Helm 图表 (Kubernetes)

GitLab Helm 图表 由多个子图表组成，其中之一是 Mailroom 子图表。
配置 incoming_email 的通用设置 和 service_desk_email 的通用设置。

Linux 包 (Omnibus)

在多节点 Linux 包安装环境中，仅在一台节点上运行 mail_room。
可在单个 rails 节点（例如 application_role）上运行，或完全独立运行。

设置所有节点

1. 在每个节点上添加 incoming_email 和 service_desk_email 的基本配置，
   以在 Web UI 和生成的邮件中渲染邮件地址。

   在 /etc/gitlab/gitlab.rb 中找到 incoming_email 或 service_desk_email 部分：

   `incoming_email`

   gitlab_rails['incoming_email_enabled'] = true
   gitlab_rails['incoming_email_address'] = "incoming+%{key}@example.com"

   `service_desk_email`

   gitlab_rails['service_desk_email_enabled'] = true
   gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.com"

2. GitLab 提供两种方法将邮件从 mail_room 传输到 GitLab 应用。
   您可为每个邮件设置单独配置 delivery_method：

   1. 推荐：webhook（GitLab 15.3 及更高版本默认）通过 API POST 请求将邮件载荷发送到您的 GitLab 应用。
      它使用共享令牌进行身份验证。若选择此方法，确保 mail_room 进程可访问 API 端点，并在所有应用节点间分发共享令牌。

      `incoming_email`

      gitlab_rails['incoming_email_delivery_method'] = "webhook"
      
      # mail_room 可联系的 URL。也可使用内部 URL 或 IP，  
      # 确保 mail_room 可使用该地址访问 GitLab API。  
      # 请勿以 "/" 结尾。
      gitlab_rails['incoming_email_gitlab_url'] = "https://gitlab.example.com"
      
      # 应包含随机令牌的共享密钥文件。确保所有节点相同。
      gitlab_rails['incoming_email_secret_file'] = ".gitlab_mailroom_secret"

      `service_desk_email`

      gitlab_rails['service_desk_email_delivery_method'] = "webhook"
      
      # mail_room 可联系的 URL。也可使用内部 URL 或 IP，  
      # 确保 mail_room 可使用该地址访问 GitLab API。  
      # 请勿以 "/" 结尾。
      
      gitlab_rails['service_desk_email_gitlab_url'] = "https://gitlab.example.com"
      
      # 应包含随机令牌的共享密钥文件。确保所有节点相同。
      gitlab_rails['service_desk_email_secret_file'] = ".gitlab_mailroom_secret"

   2. 在 GitLab 16.0 中弃用，计划在 19.0 中移除：
      若 webhook 设置出现问题，使用 sidekiq 通过 Redis 直接将邮件载荷传递到 GitLab Sidekiq。

      `incoming_email`

      # 使用 Redis 配置直接添加 Sidekiq 作业
      gitlab_rails['incoming_email_delivery_method'] = "sidekiq"

      `service_desk_email`

      # 使用 Redis 配置直接添加 Sidekiq 作业
      gitlab_rails['service_desk_email_delivery_method'] = "sidekiq"

3. 在不应运行邮件摄取的所有节点上禁用 mail_room。
   例如，在 /etc/gitlab/gitlab.rb 中：

   mailroom['enable'] = false

4. 重新配置 GitLab 使更改生效。

设置单个邮件摄取节点

设置所有节点并禁用 mail_room 进程后，在单个节点上启用 mail_room。
该节点定期轮询 incoming_email 和 service_desk_email 邮箱，并将新未读邮件移动到 GitLab。

1. 选择一个额外处理邮件摄取的现有节点。

2. 为 incoming_email 和 service_desk_email 添加 完整配置和凭据。

3. 在该节点上启用 mail_room。
   例如，在 /etc/gitlab/gitlab.rb 中：

   mailroom['enable'] = true

4. 在该节点上 重新配置 GitLab 使更改生效。