Skip to content
FunCoding

Search

Search docs, Skills and MCP

GitLab Todos 渠道

配置事件模板与项目权限,理解游标、失败及公开回复的限制。

This page has not been translated into English yet. The original Chinese version is shown below.

GitLab 渠道轮询账号的待办通知,用 Issue 和 Merge Request 上的事件驱动任务。它的失败恢复语义与 GitHub 渠道不同,部署前应先确认游标和回复可见性符合用途。

认证和模板

PAT 需要 read_api 与 api,用于读取 Todos/项目和发表 note。baseUrl 默认 https://gitlab.com,自托管填写实例根 URL,不加 /api/v3。默认 pollInterval 为 60000 毫秒。

{
  "channels": {
    "gitlab-work": {
      "type": "gitlab",
      "token": "$GITLAB_TOKEN",
      "groupPolicy": "allowlist",
      "groups": {
        "owner/repo": {
          "senders": "allowlist",
          "allowedUsers": ["operator-username"]
        }
      },
      "operators": ["operator-username"],
      "sessionScope": "chat_thread",
      "cwd": "/path/to/project",
      "action_prompt_template": {
        "mentioned": "Project: %project% | Author: %author% | Title: %title%"
      }
    }
  }
}

替换示例值、提供 GITLAB_TOKEN 后运行 qwen channel start gitlab-work。action_prompt_template 决定处理哪些 action;未配置的 action 会静默跳过并标为 done。directly_addressed 未单独配置时回退到 mentioned 模板。

可用 action 为 mentioned、directly_addressed、assigned、review_requested、approval_required、marked、build_failed、unmergeable、merge_train_removed。模板支持 %project%、%project_url%、%author%、%target_type%、%iid%、%title%、%description%、%todo_id%;%% 输出字面百分号,未知变量原样保留。

模板结果是补充 metadata。触发评论或描述本身已作为主输入并去掉 @bot,不需要发明 %body% 字段。适配器将分发的事件标记为已提及,实际事件筛选靠模板 action,不能把 requireMention 当成对所有 action 的第二道文本提及过滤。

项目和成员授权

所有请求都属于群流量。groupPolicy 默认 disabled,需按项目路径允许、配对批准或明确开放。群成员默认 open,公开项目应使用群内 senders: allowlist;privatePolicy 和顶层 allowedUsers 不限制项目成员。共享会话管理另需 operators。

配对批准绑定 owner/repo 项目路径,改名、转移或删除后撤销旧记录。即使群准入或预检拒绝请求,相关 todo 也可能被标记 done 并推进处理位置,不应期待修改权限后自动补跑。

初始化、失败和重试

首次轮询会把现有 pending todos 全部标为 done,只建立最大 ID 游标,不执行历史任务。后续较旧 ID 也尽力标为 done。

目标 URL 带 #note 锚点时使用 todo.body,否则使用描述;仅带入这次触发内容,不自动补全讨论历史。分发成功或失败都会推进游标。失败会尝试留下错误评论,不自动重试;需要重做时,应修正原因后发起新的提及。

评论触发可显示 👀,尽力在结束后移除;描述触发没有相同的 note 反应目标。当前仅处理 Issue、Merge Request,不覆盖 Epic、Design、Alert。

内部 note 的公开回复

适配器可能处理 confidential/internal note 输入,但回复 note 始终按公开方式创建,不保留原 note 的私密可见性;当前路径没有可用的可见性过滤配置。

因此,不应通过内部 note 触发包含私密内容的回答。平台输入可见性和机器人输出可见性在这里不是同一约束,不能仅凭原评论标记就判断回复也受相同限制。