Gitlab单仓(Main_Repo)循环依赖问题的优化方案咨询

方案一：自动化联动依赖包的版本更新流程 #

• 在Main_Repo的CI流水线中，当api_client成功发布到Github后，立即触发user_of_api_client仓库的自动化工作流：
  1. 自动检测api_client的新版本，更新user_of_api_client的依赖配置（比如requirements.txt或pyproject.toml）
  2. 自动提交PR到user_of_api_client仓库，同时触发该仓库的测试流水线
  3. 若user_of_api_client的测试通过，通过分支保护规则+自动化验证自动合并PR
• 在Main_Repo的流水线中添加等待环节，直到user_of_api_client的PR合并完成后，自动更新runtime_app依赖的user_of_api_client哈希值，再执行端到端测试

方案二：让runtime_app直接依赖本地api_client #

• 修改runtime_app的依赖配置，添加对Monorepo内本地api_client的直接依赖，比如在pyproject.toml中配置：

  dependencies = [
    "api_client @ file://../job_manager/api_client",
    "user_of_api_client @ git+https://github.com/xxx/user_of_api_client.git@<hash>"
  ]
  

• CI环境安装依赖时，优先使用本地的api_client版本，跳过user_of_api_client带来的间接依赖，确保端到端测试使用最新的api_client代码

方案三：统一版本管理，替换哈希依赖为版本范围 #

• 为api_client和user_of_api_client启用语义化版本号管理：
  1. api_client每次发布时，更新版本号并推送到PyPI
  2. user_of_api_client依赖api_client的兼容版本范围（比如>=1.2.0,<2.0.0），确保非破坏性更新无需手动修改依赖
• 在Main_Repo的流水线中，api_client发布到PyPI后，触发user_of_api_client的版本更新（若需要），然后让runtime_app依赖user_of_api_client的最新版本号而非固定哈希，减少手动更新步骤

方案四：使用临时测试包完成端到端验证 #

• 在Main_Repo的CI流水线中，先将更新后的api_client上传到Gitlab私有包仓库（而非正式PyPI），生成临时测试版本
• 临时修改user_of_api_client的依赖为该临时测试包，触发其测试流程验证兼容性
• 验证通过后，再正式发布api_client到PyPI，更新user_of_api_client的正式依赖版本，最后同步到Main_Repo完成流水线

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