別のプランのビルドが正常に完了したときに、プラン ビルドをトリガすることができます。これによって、あるプランに関連するジョブのソース コードに対する変更が、別の従属プラン(「子」プランとも呼ばれます)のビルドを破壊しないようにします。
たとえば、Bamboo に2つのプランがあるとします。
- Acme – Core — アプリケーションのコア コードが含まれています。
- Acme – Plugin — アプリケーションのプラグインのコードが含まれています。
このシナリオでは、Acme – Plugin プランが Acme – Core の子となります。Acme – Coreに関連するソース コードに対する変更は、Acme – Plugin のビルドをトリガする必要があります。
このページの内容
従属プランのトリガ
このプランが正常にビルドされたときに子プランがビルドされるようにトリガする方法
- ダッシュボードをクリックし、すべてのプラン タブをクリックします。
- リスト内でプランを見つけ、編集アイコンをクリックして、プランの設定ページを表示します。
- 依存関係タブをクリックします。
- 「子プラン」で、プランの検索にプラン名を入力し、トリガする子プランを選択します。トリガされるプランは複数設定することができます。
- 保存をクリックします。
Maven 3 による依存関係の自動管理
依存関係の自動管理は、Maven 3 を使用するユーザー向けの機能であり、Maven の pom.xml の依存関係に従って親と子の依存関係をセットアップすることができます。プランが実行されるたびに、Bamboo 自動依存関係が更新され、Maven 依存関係の追加または削除を反映します。
依存関係の自動管理のセットアップ
- ダッシュボードをクリックし、すべてのプラン タブをクリックします。
- リスト内で計画を見つけ、編集アイコンをクリックして、計画の設定ページを表示します。
- Locate the job that contains the pom.xml you wish to use to automatically update plan dependencies by analysing a Maven pom file.
- アクション > ジョブの設定を選択します。
- タスク タブをクリックします。
Click Add Task and add the Maven Dependency Processor task to the job. For best results, ensure that the task runs last by dragging it to the bottom of the task list. For more information on configuring tasks, see Configuring tasks.
設定 注意 プロジェクト ファイルのオーバーライド オプション。プロジェクト ファイル(pom.xml)のある作業ディレクトリまたはサブ作業ディレクトリに対する相対位置。 Working Sub Directory オプション。タスクがプロジェクト ファイル(pom.xml)を探すサブ ディレクトリ。 別の settings.xml の場所 オプション。タスクが特定の Maven リポジトリからの依存関係を解決する必要がある場合に使用される別の settings.xml を指定します。 Maven ローカル リポジトリのパス オプション。依存関係の解決に使用するタスクのローカル Maven リポジトリのフル パスを指定します。 - 保存をクリックします。
- プラン ナビゲータを使用して、プランに戻ります。
- 依存関係タブをクリックします。
- 依存関係の自動管理を選択します。Maven 依存関係プロセッサを表示するように設定したジョブの名前が表示されます。
- 保存をクリックします。
依存関係ブロック
Dependency blocking is an advanced feature of dependent build triggering that can be used to manage plan builds with parent build dependencies. This ensures that a "tree" of dependent builds always runs in tree hierarchy order, even if child plan builds are triggered independently of their parents. For more information, see Dependency blocking strategies. Please note, dependency blocking only works when the plan build is triggered because of source repository code updates.
注意
Build dependencies work together with the trigger configuration of plans to trigger builds of these plans. For example, you can set up Plan A to poll its repository for changes as well as to be dependent on a parent plan (Plan B). In this case, builds of Plan A will be triggered when code changes are detected in its repository and also when builds of Plan B complete successfully.
If you want your builds to only be triggered by successful parent builds from your build dependencies, don't configure triggering for your child plans at all. See Running a plan build manually.
- 子ビルドが親ビルドと同じソースを使用する場合(Subversion URL が同じ場合など)、子ビルドは強制的に、親ビルドと同じリビジョンのソース コードをチェックアウトします。これによって、あるビルドから別のビルドをトリガする場合に、ビルドの整合性を保ちます。
- Take care not to create circular dependencies, where your child build triggers one of its parent builds. Otherwise your plans may build continuously. See Running a plan build manually.
7 Comments
Anonymous
Jan 18, 2011Hmmm... am I the only one to think that these terms parent and child kind of oddly defined in Bamboo. I think they in other areas in sw development there meaning is vice-versa? And also maybe parent and child are not good terms to be used for dependencies.
Anonymous
Jul 21, 2011I agree, these child and parent terms are confusing.
Anonymous
Aug 12, 2011How do we get the Artifact Sharing to come up? I don't see that when I look and I'm on 3.2. Under Manual Dependency I only see a list of all the plans and I can choose plans to be a child or parent of the plan I'm on?
Nimitt Desai
Oct 19, 2012I am using dependency to trigger build plans.
e.g. Plan A, if successful will trigger plan B which if successful will trigger plan C.
Consider following situation.
Developer X, commits and that triggers Plan A to build successfully.
Plan A then tiggers to build Plan B which also builds successfully.
Plan B then triggers Plan C which fails.
In this case I would expect Bamboo to send "Build failed" email to Developer X. This does not happen.
Notification is set to "Send email to Responsible User" if build fails.
It seems Bamboo can't figure out who the responsible developer was if a dependent plan fails.
Help me fix this issue.
James Dumay
Oct 23, 2012Hi Nimitt,
This isn't possible right now. Please raise a feature request and we can see what we can do.
Thanks
James
Anonymous
Feb 06, 2013I agree the definition of parent/child is confusing on many levels especially with regard to "automatic dependency management'.
Maven allows multi-module projects. There may be parent/child relationships both within and external to a given pom. For example we have a "company' pom that defines standard configuration that should be used by all projects. A multi-module project may have a "top level" pom that claims the company pom as it's parent and then each individual sub-module claims the top level as its parent.
It is unclear to me from the documentation where the "analysis" of the pom and determining automatic dependencies comes in. The company pom doesn't know about the multi-module project so I'm assuming this isn't the automatic trigger? Analyzing the pom for dependencies would suggest the need to build things BEFORE this project so I'm assuming that's not it either.
I would suggest a complete example is needed to clarify the definitions and operational intents.
jeff mease
Sept 10, 2014I am having the same issue in 5.4.1. I am not able to even add the child plans to the build plans. You can no type it because bamboo is using a crazy character between the plan name and plan key , I also for some reason cant click the items in the drop down to select them.