不同仓库的PR合并时如何自动合并另一仓库的关联PR？

该需求完全可实现，你提出的在仓库B侧部署CircleCI流水线调用接口完成自动合并的方案是可行的，同时存在几种维护成本更低的实现路径，可根据你当前的技术栈选择。

• 你初始设想的仓库B侧CircleCI流水线方案
  实现逻辑很直接：给仓库B的CircleCI配置仅在PR合并事件触发的任务，任务执行时先提取当前已合并PR携带的仓库A关联PR标识——建议你在仓库A侧触发创建仓库B PR的步骤里，就把源PR编号、仓库A的标识直接写在仓库B的PR标题、描述固定字段或者自定义标签里，不需要后续反查提交记录做匹配，能避免匹配错误。提取到关联信息后，直接调用你所用代码托管平台的PR合并接口，使用提前存好的、拥有仓库A PR操作权限的Token完成鉴权即可。
  这个方案的优势是完全复用你现有CircleCI技术栈，不需要引入额外工具；劣势是需要自行编写接口调用、异常重试、错误通知的逻辑，同时要维护Token的定期轮转。

• 代码托管平台原生Webhook触发方案（资源占用更低）
  不需要跑完整的CircleCI流水线，直接在仓库B配置Webhook，监听PR关闭事件，筛选出merged=true的事件推送到你现有可接收HTTP请求的运行环境（比如已有的Serverless函数、内部服务接口），后续关联PR匹配、校验、合并的逻辑和上述方案一致。
  这个方案的优势是触发延迟更低，不会占用CircleCI的运行额度；劣势是需要你有现成的HTTP服务入口，如果没有额外部署服务的条件，性价比不如直接用CI流水线。

• 代码托管平台原生工作流方案（配置成本最低）
  如果你使用的是GitHub/GitLab这类自带CI工作流的托管平台，可以直接在仓库B配置原生工作流，触发条件设为PR合并时，直接用平台官方提供的PR操作组件完成关联PR的合并，不需要自行编写API请求、鉴权逻辑，凭据可以直接存在仓库的密钥管理中。
  这个方案的优势是配置量极小，不需要自行处理API签名、错误重试这类通用逻辑，维护成本最低；如果你的团队没有强制要求所有流水线必须跑在CircleCI上，这是最省心的选择。

• 不要靠提交哈希、提交信息反查关联PR，一定要在创建仓库B的PR时就把仓库A的源PR信息作为固定属性绑定，避免多PR并行时匹配错误。
• 自动合并前必须加校验逻辑：确认仓库A的对应PR处于开放状态、已通过所有CI检查、无代码冲突，校验不通过时不要执行合并，发送通知提醒人工介入即可，避免误操作。
• 用于操作仓库A的Token要做最小权限配置，仅授予PR状态查询、PR合并的权限，不要授予代码提交、仓库设置这类高危权限，所有密钥都存在CI/平台的密钥存储中，不要硬编码在脚本里。

内容的提问来源于stack exchange，提问作者AFortunato