【发布时间】：2014-01-31 04:21:58
【问题描述】：
我们有一个发布构建结构，看起来像这样：
U 项目（上游）：
- 是矩阵项目
- 在多个平台上运行，为每个平台创建发布的文件。
- 这些将颠覆修订号放入各种文件中。
- 将工件归档回 Jenkins
- 触发器基于项目 D
项目 D（下游）：
- 不是矩阵项目
- 只检出顶级目录和包含发布脚本的子目录
- 从项目 U 的成功构建中提取工件
- 使用颠覆修订号来决定将合并结果复制到哪里。
我不知道这是否是正确构造它以解决 Jenkins 局限性的方法，但这是我们能够解决的唯一方法，因为它非常缺乏有用的文档。
不管怎样，我们遇到的问题是这样的事情发生了：
- 18:00 触发器启动 Project U
- Project U 签出 SVN 修订版 30,000 并构建软件
- 18:05，一些在办公室工作的人签入了一些新代码
- 项目 U 于 18:25 完成构建并触发项目 D
- 项目 D 签出 SVN 修订版 30,001 并进行上传
结果是我们的 Web 服务器上的文件最终在发布过程中认为是 30,001 版本，但实际上是 30,000。
（请注意，这不仅适用于发布版本。我们也看到它用于单元测试 - 编译软件的版本和运行测试的版本可能是不同的版本，导致测试依赖于检查源目录的内容失败，因为某些源文件没有对应的编译文件。）
我尝试使用“参数化触发器”插件来传递 Subversion 修订版，但仅将其配置为传递修订版号似乎还不够，因为触发的项目没有使用它正在使用的数字通过了。我在第二个项目中找不到与此相关的任何设置，但 Jenkins 的 UI 是狗的早餐，如果有人能在其中找到任何东西，我会感到惊讶。
有谁知道如何做这种事情？ 肯定我们不是世界上唯一一家试图在多个平台上发布我们的软件的公司吗？
【问题讨论】：
-
FWIW，我目前使用的解决方法是在项目D中使用单个顶级目录。所以我必须支付检查项目很多无用部分的费用，但是这样做可以避免导致“参数化触发器”不起作用的错误。
标签： svn build jenkins multiplatform