【发布时间】：2014-02-25 20:44:56
【问题描述】：
我们正在使用一系列 shell 脚本，我正在尝试通过使用 Jenkins 对其进行改进（以便获得更多控制权，并允许不熟悉 shell 脚本的开发人员在需要时理解和更改流程）。
我对涉及基本上使用 SVN 检查项目、使用 Maven 构建并将战争部署到我们的容器的脚本没有任何问题。
但现在我正在尝试创建一个 Jenkins 作业来为我们的客户打包 Linux、Linux x86_64 和 Windows 安装程序。该脚本执行以下操作：
- 签出项目（SVN）；
- 使用测试配置文件 (Maven) 构建主项目；
- 将战争复制到 Samba 共享 (smbclient)；
- 使用生产配置文件重建项目；
- 更新 Linux、Linux64 和 Windows 文件夹中的版本化 (SVN) 文件夹；
- 复制linux文件夹中的war；
- 使用 Linux 文件夹创建一个 tarball；
- 复制Linux64文件夹中的war；
- 使用 Linux64 文件夹创建一个 tarball；
- 将战争复制到 Windows 文件夹中；
- 使用在 Wine 上运行的 InnoSetup 创建一个 Windows 可执行文件；
- 将包复制到 Samba 共享。
这个脚本太复杂了，Linux、Linux64 和 Windows 文件夹之间有很多冗余。我设想了一个改进的过程，我将使用以下文件夹结构：
libs
|-- unversioned-folder
|-- linux
| `-- specific linux files
|-- linux64
| `-- specific linux x86_64 files
`-- windows
`-- specific windows files
workspace
|-- main-project
`-- versioned-folder
|-- versioned-subfolder1
|-- versioned-subfolder2
|-- unversioned-folder (copied from libs)
| `-- main-project.war (built with Maven from the main-project)
`-- Linux or Linux64 or Windows specific folder (overwritten after each packaging)
这样，版本控制的文件夹不会重复，我可以打包 Linux、Linux64 和 Windows 安装程序而无需冗余，只需覆盖每个文件的特定文件。
我一直在尝试使用 Jenkins，并在脚本的第一部分使用 Publish Over CIFS 插件。但如果我继续使用相同的工作，我会意识到它会太复杂，而且大部分步骤都会发生在后期构建部分。
理想的方法是将作业分解成更小的作业，就像在 shell 脚本中调用函数一样。现在我正在研究Multijob plugin。
我想知道是否可以在 Jenkins 中使用这种层次结构，共享父作业的工作空间：
安装作业
- 签出主项目
-
子作业： 创建测试项目
- 使用测试配置文件构建主项目
- 将 war 文件复制到 Windows 共享中
-
子工作：创建生产项目
- 使用生产配置文件重建主项目
-
子工作： 创建包
- 签出版本化文件夹；
- 将未版本控制的文件夹复制到版本控制的文件夹中；
- 将主项目war文件复制到未版本控制的文件夹中；
-
sub-job: 打包linux安装程序
- 将未版本化的 linux 特定文件复制到版本化文件夹中；
- 创建一个 tarball（打包）。
-
子作业： 打包 linux x86_64 安装程序
- 复制未版本化的 linux64 特定文件；
- 创建一个 tarball（打包）。
-
sub-job: 打包 windows 安装程序
- 复制未版本化的 Windows 特定文件；
- 使用 InnoSetup 创建可执行安装程序（可能是带有 wine 的 shell 脚本）。
- 将包发送到 Windows 共享。
如果父作业的工作空间不能在子作业之间共享，我怎样才能获得与使用 Jenkins 的 shell 脚本相同的结果？
【问题讨论】：
-
与此同时，我将使用 jenkins/shell 脚本混合：1 个作业来检查、构建和复制主项目的战争到 samba 共享，第二个作业检查主项目和版本文件夹，为生产构建主项目，然后调用 shell 脚本复制未版本文件夹并打包文件。
标签： jenkins