多仓库服务CI流水线搭建：解决私有PyPI依赖包同步延迟问题

1. 调整上下游流水线触发顺序 #

• 将B仓库的Jenkins任务划分为三个串行阶段：代码合并校验 → 构建wheel包并上传私有PyPI → 触发下游依赖仓库CI
• 利用Gitlab企业版自带的上下游流水线关联能力，绑定B仓库和A仓库的触发规则，只有B的wheel包确认上传成功后，才主动触发A的CI任务，从根源上消除二者的时序差
• 如果存在多个依赖B的服务仓库，可以在Jenkins中配置统一的下游触发列表，B上传成功后批量触发所有关联仓库的CI任务，无需单独配置

2. 新增依赖版本强校验规则 #

• 每次B的master分支合并代码时，通过bump2version工具自动迭代语义化版本号，避免不同构建产物使用同一个版本号
• A仓库的CI任务执行依赖安装前，先查询私有PyPI中B的最新版本是否符合预期，查询命令参考：
  pip search --index <你的私有PyPI地址> <包B的名称>
• 若查询到的最新版本低于预期版本，直接终止CI并抛出明确的版本缺失报错，避免拉取旧版本依赖构建出错误产物

3. 配置依赖安装的等待重试策略 #

如果需要保留原有B合并后立即触发A CI的逻辑，可以在A的依赖安装步骤新增指数退避重试逻辑，示例代码片段如下：

import time
import subprocess

MAX_RETRIES = 10
BASE_INTERVAL = 30  # 初始重试间隔30秒

for retry_cnt in range(MAX_RETRIES):
    install_res = subprocess.run(
        ["pip", "install", "--index-url", "<私有PyPI地址>", "包B==<预期最新版本>"],
        capture_output=True
    )
    if install_res.returncode == 0:
        break
    time.sleep(BASE_INTERVAL * (retry_cnt + 1))
else:
    raise Exception("私有PyPI未检测到包B的最新版本，CI任务终止")

• 该方案无需调整现有触发逻辑，总重试时长可覆盖B的构建上传耗时，同时不会影响正常场景下的依赖安装速度

4. 构建节点本地缓存兜底 #

可以在所有Jenkins构建节点上配置公共依赖缓存目录，B的wheel包上传到私有PyPI的同时，同步推送到所有构建节点的缓存目录。A的CI安装依赖时优先从本地缓存拉取B包，其余依赖仍从私有PyPI拉取，进一步提升安装速度的同时保证版本正确。

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