Composer配合Jenkins触发器实现多层关联包依次自动构建发布-composer-PHP中文网

composer 不支持多层关联包自动触发构建，因其仅为单向依赖解析器，只拉取已发布包，不主动通知或触发上游ci；jenkins需手动建模依赖链或改用monorepo+path仓库方案。

composer配合jenkins触发器实现多层关联包依次自动构建发布

Composer 本身不支持“多层关联包自动触发构建”——Jenkins 无法靠 Composer 自动感知依赖变更并反向触发上游包构建，必须手动建模依赖关系或借助外部机制。

为什么 composer install 不会触发上游包构建

Composer 是单向依赖解析器：它只负责根据 composer.json 和 composer.lock 下载、安装已发布的包（如从 Packagist 或私有仓库），不会也不应主动通知或触发被依赖包（比如 myorg/core）的 CI 流程。这属于职责分离——发布是上游的事，消费是下游的事。

常见误操作是期望在 A 包的 Jenkinsfile 里写 composer update myorg/core 后，Jenkins 自动找到 myorg/core 并构建它。这不会发生，composer update 只改本地 lock 文件，不发任何 webhook，也不调用 Jenkins API。

Composer 的行为本质是“拉取”，不是“联动”
Jenkins 触发器（如 SCM Polling / Webhook）监听的是 Git 仓库的 push 事件，不是 Composer 的依赖变化
即使 myorg/core 更新了 tag，A 包也不会自动感知，除非你显式运行 composer update myorg/core 并提交新 lock

可行方案：用 Jenkins Pipeline 显式建模依赖拓扑

若 A 依赖 B，B 依赖 C，且你希望 C 更新 → B 构建 → A 构建，需人工定义依赖链，并在每个包的 Jenkinsfile 中调用 Jenkins API 主动触发下游任务。

关键点：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

每个包对应一个 Jenkins Job（如 php-lib-core、php-lib-utils、php-app-backend）
上游包成功发布后（例如打 tag 或合并到 main），在 Pipeline 最后一步用 sh 'curl -X POST ...' 调用 Jenkins REST API 触发下游 Job
下游 Job 需配置参数化构建（如接收 UPSTREAM_VERSION），并在 composer.json 中用变量控制版本约束（如 "myorg/core": "${UPSTREAM_VERSION}"）
避免循环依赖；建议用 tag（如 v1.2.0）而非 dev-main，防止不稳定快照污染下游

示例（在 php-lib-core 的 Jenkinsfile post-success 中）：

sh '''
  curl -s -X POST \
    --data token=abc123 \
    --data "UPSTREAM_VERSION=${GIT_TAG:-${GIT_COMMIT}}" \
    http://jenkins.example.com/job/php-lib-utils/buildWithParameters
'''

更稳健的做法：统一用 monorepo + workspace-aware composer

当关联包数量超过 3–4 个，硬编码上下游触发极易出错、难维护。此时应放弃分散 repo 模式，改用 monorepo 结构，配合 composer workspace（需 Composer 2.5+）或自定义脚本管理本地路径依赖。

所有包放在同一 Git 仓库下不同目录（packages/core、packages/utils、apps/backend）
根目录 composer.json 使用 path repository 声明本地依赖："repositories": [{"type":"path","url":"packages/core"}]
Jenkins 构建时，先 composer install 全局，再按需进入子目录执行测试/打包
Git 提交影响任一 package，整个流水线运行，天然保证一致性，无需跨 Job 触发

缺点是发布粒度变粗（一次 commit 可能同时更新 core 和 utils），但换来的是可预测性和可调试性——这是多数团队实际落地时选择的折中点。

容易被忽略的权限与缓存陷阱

跨 Job 触发和 monorepo 构建都绕不开两个隐形问题：

composer 运行用户权限：Jenkins agent 以 jenkins 用户执行命令，若挂载了宿主机 $HOME/.composer 目录，需确保该目录属主是 jenkins，否则 composer install 可能因权限失败或静默跳过 cache
私有包认证泄漏风险：不要在 Jenkinsfile 中硬编码 github-oauth；使用 withCredentials 绑定凭证，并在 sh 步骤中临时写入 auth.json，用完即删
lock 文件提交策略：composer.lock 必须提交到 Git；否则下游构建可能因未锁定版本而拉取意外更新，破坏可重现性