Jenkinsのビルドで使用するgitブランチを動的に選択する方法

Jenkinsのビルドサーバー用に新しいプロジェクト設定を作成しようとしています。私がやろうとしていることを単純化するために、私は問題を説明するために2つのコンポーネントだけを使用します。

コンポーネントA

  • このコンポーネントの変更をトリガーとして、CIサーバー上でこのプロジェクトのビルドが行われます。
  • CIサーバーには、変更を監視してビルドするためのブランチが静的に設定されています。例えば、masterブランチやdevelopブランチなどです。
  • このコンポーネントは、依存するComponentBの必要なバージョンを含む設定ファイルを含んでいます。

コンポーネントB

  • このコンポーネントの変更は、CIサーバー上のこのプロジェクトのビルドをトリガーしません（ComponentBの開発をカバーする別のプロジェクトが存在します）。
  • コンポーネントの個々のバージョンはタグ付けされています
  • ComponentAがComponentBの必要なバージョンを設定ファイルに入れている。
  • CIサーバーは、ComponentAの設定ファイルが何らかの方法で解析されるまで、どのブランチ（タグ）をチェックアウトすればよいのかわからない。

Jenkinsでこれを実現するための正しい方法は何でしょうか？設定ファイルを解析して、ComponentBの予想されるバージョンに基づいてブランチをチェックアウトするGit Pluginを作るという動的な動作を追加する方法を見つけようとしていたのですが、今のところ手がかりはありません。

次のステップでは、設定ファイルにワイルドカード（5.3.*のような）を入れて、ワイルドカードに一致する最新のComponentB'sタグを見つけるようにすることも考えています。

EDIT

今となっては、問題を単純化しすぎて、単純化したために主な制約がなくなってしまったのだと思います。

主な制限は、コンポーネントAとコンポーネントBを一緒にビルドする必要があることです。これらは1つの実行ファイル/ライブラリであり、ビルドスクリプトは両方のコンポーネントのソースファイルを必要とするため、別々にビルドすることは不可能です。

なぜこのような不思議な構成になっているのかというと、コンポーネントA、コンポーネントBについて説明します：

  • ComponentA：ネイティブプラットフォーム専用コード
  • ComponentB：ネイティブプラットフォーム非依存コード

特定のAをBにマージすると、単一プラットフォーム用の完全なソースコードが作成されますが、すべてのプラットフォームがBの最新バージョンに更新されるとは限らないため、ビルドに使用するBのバージョンを制御する必要があります。

Ladislav Mrnka
編集された質問 24日 4月 2017 в 11:41
プログラミング
continuous-integration build git jenkins
3日 4月 2017 в 11:30
まだビューはありません
質問へのコメント (7)
ソリューション

あなたが望むことを実現するための一つの選択肢は、次のような設定を使用することです：

Jenkinsのジョブを2つ作成します：

  • コンポーネントA"（SCMの変更に伴い自動的にトリガーされます。） -"コンポーネントB" ("manual" トリガー)

ステップ#1

コンポーネントB"のbranch ビルドパラメータを定義します：

[[ここに画像の説明を入力]][1][1]。

このパラメータを "Git Plugin" ブランチ指定子として使用します：

[[ここに画像の説明を入力]][2][2][2][2][2][2][!

これで、手動で "Component B" ビルドを起動することができるようになりました。

Step #2

ワークスペースの設定ファイルからコンポーネントB&quotのバージョンを抽出し、コンポーネントB&quotのビルドパラメータを含むb.propertiesファイルを準備します。

[[ここに画像の説明を入力]][3][3][3][3][3][3][!

Jenkinsのプラグイン「Parameterized Trigger」(https://plugins.jenkins.io/parameterized-trigger)をインストールし、「コンポーネントA」のジョブに新しいビルドステップ「Trigger/Call Builds on Other Projects"」を追加します：

[[ここに画像の説明を入力]][4][4]です。

ビルドパラメータのソースとして b.properties ファイルを使用します。

これで、"Component A"が再ビルドされるたびに、ターゲットブランチ/タグをビルドパラメータとして、新しい"Component B"のビルドがトリガされるようになりました。

ワイルドカードのサポート追加

ワイルドカードのバージョンをサポートしたい場合は、git ls-remoteコマンドを使って、そのように最新のタグを検索することができます：


#B=$(obtain B version from the config file in a usual way)   

LATEST=$(\
    git ls-remote --tags YOUR_REPOSITORY_URL "$B"\
    |cut -d / -f3|sort -r --version-sort|head -1\
)

cat
zeppelin
編集した答え 24日 4月 2017 в 8:35
解説 (3)

Credentials Binding Plugin]1を使用すると、非常にうまくいきました（@zeppelin氏も言及しています）。

Steps

グローバル資格情報セクションにあります：

1.タイプのAdd Credentialsを追加します："Username with password".これは、HTTPSプロトコルを使用したコンポーネントBのリポジトリgitサーバーのユーザー名とパスワードでなければなりません（SSHオプションはこの目的には適していません）。

[ここに画像の説明を入力]222[!

Jenkinsのジョブ構成で：

2.コンポーネントAを通常のソースコード管理のGitセクションの下にすべての必須フィールド（リポジトリ、ブランチなど）を配置します。

  • リポジトリはサブディレクトリに置くとスッキリします：Additional Behaviours で Check out to a sub-directory を選択し、次のように記述します：Component_a` 3.ビルドトリガー** の「変更がGitHubにプッシュされたときにビルドする」にもチェックを入れてください。 4.ビルド環境]セクションで、[秘密のテキスト（複数可）またはファイル（複数可）を使用する]をチェックします。
  • 変数`に名前：MY_CREDを入れる。
  • で、ステップ1で作成した特定の認証情報を選択します。

[ここに画像の説明を入力]333[! 5.これで、Execute shellのコードでMY_CREDを使用すると、コンポーネントBのリポジトリにアクセスできるようになります：

    DIR="component_b&quot；
    if [ "$(ls -A $DIR/.git)" ]; then
        cd $DIR
        ギットフェッチ
    然も
        git clone https://$MY_CRED@github.com/proj/component_b.git $DIR
        cd $DIR
    フィー
    ギットショー

[ここに画像の説明を入力]4です。

  • 注: ログにユーザーとパスワードは表示されませんので、安全です：git clone 'https://**@github.com/proj/component_b.git' component_b`.

6.コンポーネントAのconfigをすべて解析して、目的のタグを取得します：TAG=$(cat ./component_a/config.cfg | grep ... | sed ...). 7.目的のTagをチェックアウトする：cd component_b; git checkout -f $TAG.

  • 注意：-fフォースタグ。 8.このコードを実行し、希望通りにテストしてください...。
解説 (1)

1 - プロジェクトBをプロジェクトAのサブレポとして追加することは、可能な解決策でしょうか？

2- (Bのソースコード全体を含めることが本当に避けられるなら) : Bのビルドを B_builds レポジトリにプッシュし、このレポジトリを A のサブレポとして追加することは、可能なソリューションでしょうか？

理由 : A と B の依存関係をより明示的にする一つの方法は、リポジトリの依存関係の中にそれを表現することである。

この場合、Aプロジェクトを管理する際に、余分なステップを追加する必要があります：

update `B` sub repo in `A` project, and push this to `A`

を作成するたびに、Bの新しいバージョンを作成します。

しかし、Aからは、Bのバージョンがいつ統合されたかを明確に把握することができ（例："我々は、A 4.3.2 から B 2.0.1 しか使っていない）、Aにプッシュすると通常のJenkinsフローが発生します。

解説 (0)