Jenkins实现任务间依赖调度有三种主流方式：1. 使用“Build other projects”构建后操作，适合简单串行依赖；2. 在Pipeline中用build步骤显式调用，支持参数传递、错误传播与等待控制；3. 利用Parameterized Trigger插件实现条件触发、多下游并发及参数化调度。
1. 使用“Build other projects”构建后操作（适合简单串行依赖）
这是最直观的图形化配置方式，无需写代码，适用于“任务A成功 → 立即触发任务B”的基础链路。
- 进入上游任务（如 build-job）的配置页 → 滚动到Post-build Actions（构建后操作）部分
- 选择Build other projects（构建其他项目）
- 在Projects to build中填写下游任务名称（如 deploy-job）
- 勾选Trigger only if build succeeds（仅成功时触发），可选勾选Trigger even if the build is unstable（不稳定时也触发）
- 保存后，每次 build-job 构建成功，Jenkins 就会自动排队启动 deploy-job
⚠️ 注意：该方式不支持条件分支（如“失败则发告警，成功才部署”）、多下游并行或参数传递，但稳定性高、排查简单。
2. 在 Pipeline 中用 build 步骤显式调用（推荐用于可控流水线）
当使用 Jenkinsfile 管理流程时，可在脚本中直接调用其他任务，并精确控制等待、超时、参数和失败策略。
- 在 Pipeline 的某个 stage 中使用 build DSL 函数，例如：
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean package'
}
}
stage('Deploy') {
steps {
build job: 'deploy-prod', wait: true, propagate: true
}
}
}
}
- wait: true 表示当前 Pipeline 会阻塞等待下游任务完成
- propagate: true 表示若下游失败，本 Pipeline 也标记为失败（保持状态一致性）
- 支持传参：
build job: 'deploy-prod', parameters: [string(name: 'VERSION', value: env.BUILD_ID)]
✅ 优势明显：版本可追溯、支持错误处理、能嵌套多级调用、与 SCM 联动自然。
3. 利用 upstream/downstream 插件或 Parameterized Trigger（增强型触发）
当需要更灵活的触发逻辑（如根据上游构建参数动态决定是否触发、多条件组合、异步非阻塞调用），可安装官方插件增强能力。
- 安装插件：Parameterized Trigger Plugin（推荐）或 Upstream/Downstream Plugin
- 在上游任务配置中，Post-build Actions 里选择Trigger parameterized build on other projects
- 可设置：
- 触发条件（成功 / 不稳定 / 总是）
- 向下游传递构建参数（如 Git 分支名、环境标识）
- 定义触发前的预检查脚本（Shell 或 Groovy）
- 支持并发构建多个下游任务（如同时部署到 dev & test 环境）
? 典型场景：CI 流水线中，单元测试通过后，按需触发集成测试 + 安全扫描两个独立任务，且各自接收不同参数。
补充：避免常见陷阱
依赖调度容易忽略的关键点：
- 权限问题：下游任务需对上游任务有“Build”权限；建议统一用 service account 运行，避免个人账号 token 失效
- 循环依赖：A 触发 B，B 又触发 A → Jenkins 会拒绝保存或导致死锁，配置时务必检查依赖图
- 静默失败：下游任务若被禁用、缺少凭证或节点离线，Jenkins 默认只记录警告，不会中断上游；建议配合邮件/钉钉通知插件做失败兜底
- 时间错位：依赖 ≠ 定时。不要在下游任务里再配 Cron，否则可能重复执行或错过上游结果
