【问题标题】：trigger a release build of Jenkins using a plugin使用插件触发 Jenkins 的发布版本
【发布时间】：2016-08-02 20:27:42
【问题描述】：
我正在尝试在 Jenkins 中进行如下构建推广：
- Jenkins 作业 A 构建产品快照
- A 有下游作业 B，它将 A 快照部署到测试环境。
- B 有一个下游作业 C，它在测试环境中的 Prod A 上运行测试。
- 如果 C 成功，我想通过启动作业 A 的发布版本来推广作业 A；
这将启动将发布版本部署到 Prod env 的作业 B；将启动作业 C 以在 Prod env 上运行测试。
如果 C 成功，只需向所有人发送邮件。它不应启动 A 的另一个构建。
我正在尝试使用可以设置标准的构建提升插件。
但在“操作”部分，我如何才能启动 A. 的发布版本？
另请注意，第一轮是 A 的快照构建。当 C 成功时，我只想触发一次 A 的发布构建。它不应该一直循环下去。
如果您有其他更好的想法来实现此功能，请告诉我
谢谢
【问题讨论】：
标签：
jenkins
jenkins-plugins
【解决方案1】：
使用两个工作链：
- 一组用于快照的作业 A/B/C（例如，
A-snap/B-snap/C-snap），以及
- 要发布的另一组作业 A/B/C（例如，
A-rel/B-rel/C-rel）。
配置A-snap的推广，使其触发A-rel。不要对A-rel 使用升级（或使用不同的操作来处理成功的发布）。 这将防止您提到的“循环问题”。
一开始复制作业看起来很尴尬，但是在使用某些框架自动生成作业时会很简单（例如Job DSL plugin）。另一方面，您最终会得到一个更清晰的设置，因为您将避免相同作业实际上执行不同任务（这里：快照和发布相关的构建/部署/测试）。 这还有其他好处：
- 快照和发布任务可以并行运行（如果您有资源）
- 如果构建作业与 SCM 相关联，那么混合使用快照/发布构建会导致混乱（错误的更改日志、错误的指责）
- 即使不与 SCM 绑定，如果不在同一个工作中混合快照/发布版本，可追溯性会更好。
关于您的问题“1.”：实际触发 A-rel 将很简单（有 Build other projects 操作）。不过，您需要确保 A-rel 将在当前正在升级的同一快照版本上运行。