How to manage a common ant build script across multiple project build jobs on jenkins?

后端 未结 3 2055
你的背包
你的背包 2020-12-01 15:35

I have a set of java projects coming from different git repositories which I want to be built with Jenkins.

All of them share the same ant build script, which employ

相关标签:
3条回答
  • 2020-12-01 15:51

    A couple of ideas...

    1. Store the Ant script in an artifact repository that your individual projects can pull from, like any other dependency.
    2. Create a parent Git project that contains the build script. In your parent project, pull down each individual sub-project as a Git submodule. You would probably need to make some minor modification to your script in order to parameterize the sub-project references in the build script.

    This answer is not specific to Jenkins and should be portable to other build servers.

    0 讨论(0)
  • 2020-12-01 15:58

    I have also found another option myself:

    Declare the "overrideable" part in the common build script as "neutral" element, e.g. for a path definition define an empty path:

    <path id="additional-classpath" />
    

    Optionally import another build script after the neutral defintion to make it override the existing one:

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

    In the imported file you now can define the element to suit the individual needs of the project to build.

    0 讨论(0)
  • 2020-12-01 16:11

    Not an uncommon problem as @whiskeyspider states it's not confined to Jenkins. In my opinion it's also one of the issues that holds backs large legacy ANT builds. Over time it gets harder and harder to change the common logic due to a justifiable fear that it breaks dependent builds.

    Keeping the common logic in a separate repository or a git submodule is sound advice because it enables version control of this logic. Another option is to package the common logic as an 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>
    

    While it appears more complicated I maintain creating these kinds of common tasks makes for a more reusable and readable build file. It also makes it obvious what your organisation's customisations are. I find it especially useful for hiding implementation details that might involve nasty embedded scripts.

    Finally I'm a big fan of using ivy for managing my 3rd party dependencies. This means I can easily download whatever version of the common logic my build needs from my repository.

    How to create an 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>
    

    Note:

    • This example has a single task. In reality your common build logic would provide multiple macrodefs.

    build.xml

    Just jar up the XML file:

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

    My build logic additionally would publish this jar file into my repository, so that other builds can pull it down using ivy. Also means that the common build logic can have a separate and formal release management life-cycle (Very important in a large organisation)

    0 讨论(0)
提交回复
热议问题