4

JenkinsでビルドしたいさまざまなgitリポジトリからのJavaプロジェクトのセットがあります。

それらはすべて同じantビルドスクリプトを共有します。このスクリプトは、antインポートメカニズムを介してプロジェクト固有の構成部分（コンパイルクラスパスなど）を使用します。

現時点では、この共有を手動で行っていますが、共通部分を変更するとエラーが発生しやすくなります。

だから私の質問は：jenkinsサーバー上の複数のビルドジョブ間で共有されたAntビルドスクリプトを管理するための良いアプローチは何ですか？

4

3 に答える 3

6

@whiskeyspiderは、Jenkinsに限定されていないと述べているため、珍しい問題ではありません。私の意見では、これは大規模なレガシーANTビルドを妨げる問題の1つでもあります。時間の経過とともに、依存するビルドを壊すという正当な恐れがあるため、共通論理を変更することはますます難しくなります。

共通ロジックを別のリポジトリまたはgitサブモジュールに保持することは、このロジックのバージョン管理を可能にするため、適切なアドバイスです。別のオプションは、共通論理をANTlibとしてパッケージ化することです。

<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を使用するのが大好きです。これは、ビルドに必要な共通ロジックのバージョンをリポジトリから簡単にダウンロードできることを意味します。

ANTlibを作成する方法

├── 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>

ノート：

  • この例には単一のタスクがあります。実際には、一般的なビルドロジックは複数のmacrodefを提供します。

build.xml

XMLファイルをjarファイル化するだけです。

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

私のビルドロジックはさらにこのjarファイルを私のリポジトリに公開し、他のビルドがivyを使用してそれをプルダウンできるようにします。また、共通のビルドロジックは、個別の正式なリリース管理ライフサイクルを持つことができることを意味します（大規模な組織では非常に重要です）

于 2013-03-26T21:37:27.943 に答える
3

いくつかのアイデア...

  1. 他の依存関係と同様に、個々のプロジェクトがプルできるアーティファクトリポジトリにAntスクリプトを保存します。
  2. ビルドスクリプトを含む親Gitプロジェクトを作成します。親プロジェクトで、個々のサブプロジェクトをGitサブモジュールとしてプルダウンします。ビルドスクリプトでサブプロジェクト参照をパラメータ化するには、スクリプトに若干の変更を加える必要があります。

この回答はJenkinsに固有のものではなく、他のビルドサーバーに移植できる必要があります。

于 2013-03-26T17:20:40.757 に答える
0

私はまた別のオプションを自分で見つけました：

一般的なビルドスクリプトの「オーバーライド可能」部分を「ニュートラル」要素として宣言します。たとえば、パス定義の場合、空のパスを定義します。

<path id="additional-classpath" />

オプションで、ニュートラル定義の後に別のビルドスクリプトをインポートして、既存のスクリプトをオーバーライドします。

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

インポートされたファイルで、ビルドするプロジェクトの個々のニーズに合わせて要素を定義できるようになりました。

于 2014-06-30T09:19:02.680 に答える