如何在jenkins上跨多个项目构建作业管理常见的ant构建脚本?

时间:2013-03-26 17:05:35

标签: java ant jenkins continuous-integration

我有一组来自不同git存储库的java项目,我想用Jenkins构建它们。

所有这些脚本共享相同的ant构建脚本,该脚本通过ant导入机制使用项目特定的配置部分(例如编译类路径)。

目前我手动进行此共享,但在更改公共部分时非常容易出错。

所以我的问题是:在jenkins服务器上跨多个构建作业管理共享ant构建脚本的好方法是什么?

3 个答案:

答案 0 :(得分:6)

不是一个不常见的问题,因为@whiskeyspider声明它不仅限于詹金斯。在我看来,这也是阻碍大型遗留ANT构建的问题之一。随着时间的推移,由于合理地担心它会破坏相关构建,因此更改共同逻辑变得越来越难。

将公共逻辑保存在单独的存储库或git子模块中是合理的建议,因为它可以对此逻辑进行版本控制。另一种选择是将公共逻辑打包为ANT lib

<project ... xmlns:common="antlib:com.example.commonbuild">

    <taskdef uri="antlib:com.example.commonbuild">
        <classpath>
             <fileset dir="${lib.dir}" includes="commonbuild-1.0.jar"/>
        </classpath>
    </taskdef>

    ..
    ..

    <target name="build">
        <common:compileAndPackage srcDir="${src.dir}" buildDir="${build.dir}" jarFile="${build.dir}/${ant.project.name}.jar"/>
    </target>

虽然看起来更复杂但我维护创建这些常见任务使得构建文件更具可重用性和可读性。它还明确了您组织的定制是什么。我发现它对隐藏可能涉及令人讨厌的嵌入式脚本的实现细节特别有用。

最后,我非常喜欢使用ivy来管理我的第三方依赖项。这意味着我可以轻松地从我的存储库下载我的构建需要的任何版本的通用逻辑。

如何创建ANT lib

├── build.xml
└── src
    └── com
        └── example
            └── commonbuild
                └── antlib.xml

antlib.xml

<antlib>
    <macrodef name="compileAndPackage">
        <attribute name="srcDir"/>
        <attribute name="buildDir"/>
        <attribute name="jarFile"/>
        <sequential>
            <mkdir dir="@{buildDir}/classes"/>
            <javac srcdir="@{srcDir}" destdir="@{buildDir}/classes" includeantruntime="false"/>
            <jar destfile="@{jarFile}" basedir="@{buildDir}/classes"/>
        </sequential>
    </macrodef>
</antlib>

注意:

  • 此示例只有一个任务。实际上,您的公共构建逻辑将提供多个宏定义。

的build.xml

只需清理XML文件:

<target name="build" description="Create jar">
    <jar destfile="${build.dir}/commonbuild-${version}.jar" basedir="${src.dir}"/>
</target>

我的构建逻辑还会将此jar文件发布到我的存储库中,以便其他构建可以使用ivy将其下拉。也意味着公共构建逻辑可以具有单独且正式的发布管理生命周期(在大型组织中非常重要)

答案 1 :(得分:3)

一些想法......

  1. 将Ant脚本存储在您的各个项目可以从中获取的工件库中,就像任何其他依赖项一样。
  2. 创建包含构建脚本的父Git项目。在您的父项目中,将每个子项目下拉为Git submodule。您可能需要对脚本进行一些小修改,以便在构建脚本中参数化子项目引用。
  3. 这个答案不是Jenkins特有的,应该可以移植到其他构建服务器。

答案 2 :(得分:0)

我自己也找到了另一种选择:

声明&#34;可重写&#34;参与公共构建脚本作为&#34;中性&#34;元素,例如对于路径定义,定义一个空路径:

<path id="additional-classpath" />

可选择在中性定义后导入另一个构建脚本,使其覆盖现有脚本:

<import file="compile-classpath.xml" optional="true" />

在导入的文件中,您现在可以定义元素以满足要构建的项目的个别需求。