我们有一个发布版本结构，如下所示：
项目U（上游）：
- 是一个矩阵项目
- 在多个平台上运行，为每个平台创建已发布的文件。
- 这些将subversion版本号放在各种文件中。
- 将档案文件归还Jenkins
- 在项目D上构建触发器
项目D（下游）：
- 不是矩阵项目
- 仅检出顶级目录和包含发布脚本的子目录
- 从Project U
的成功构建中提取工件- 使用subversion版本号决定合并结果的复制位置。
我不知道这是正确的方式来构建这个来解决Jenkins的局限性，但这是我们能够通过极其缺乏有用的方法解决这个问题的唯一方法文档。
无论如何，我们遇到的问题是这样的事情发生了：
结果是我们最终得到了我们的Web服务器上的文件，发布过程认为这是30,001版本，但实际上是30,000。
（这不仅仅是发布版本，请注意。我们也看到它用于单元测试 - 编译软件的构建和运行测试的构建可以是不同的版本，导致依赖于检查的测试源目录的内容失败，因为某些源文件没有相应的编译文件。）
我尝试使用“参数化触发器”插件来传递Subversion修订版，但只是将其配置为通过修订版号似乎不够，因为触发的项目没有使用它的数字通过。我找不到与此相关的第二个项目的任何设置，但詹金斯的用户界面就是这样一只狗的早餐，如果有人能找到任何东西，我会感到惊讶。
有谁知道怎么做这种事情？ 当然我们不是世界上唯一一家试图在多个平台上发布我们软件的公司？
答案 0 :(得分：3)
我认为Tracking SVN Plugin可以解决您的问题。
答案 1 :(得分：1)
您可以执行以下操作。
使用参数化插件并将SVN修订版传递给下游项目。
在下游项目中，无需选择svn作为源代码管理工具。而是添加第一个构建集以将您的工作目录更新为从上游项目传递的修订。
cd $workspace
svn update -r$pameter
我为我们的一个项目做过这样的事情并且工作正常。
如果您使用的是干净版本，而不是svn update，您也可以使用结帐方式。
svn checkout url://repository/path@$parameter
或
svn checkout -r $parameter url://repository/path