You may want to trigger a plan build when another plan's build has successfully completed. This ensures that changes to any job's source code associated with one plan does not break the build of another dependent plan (known in this context as a 'child' plan).

For example, there could be two plans in Bamboo:

  1. Acme – Core — which contains the core code for an application.
  2. Acme – Plugin — which contains code for a plugin to the application.

In this scenario, the Acme – Plugin plan is a child of Acme – Core. Any changes to source code associated with the Acme – Core plan should trigger a build of Acme – Plugin.

On this page:

Triggering dependent plans

To trigger a child plan to build when this plan builds successfully:

  1. Click Dashboard and then the All Plans tab.
  2. Locate the plan in the list and click the edit icon to display the plan's Configuration pages.
  3. Click the Dependencies tab
  4. Under 'Child Plans', begin typing a plan name in Search for plan to select child plans to trigger. You can set multiple plans to be triggered.
  5. Click Save.

Automatic dependency management with Maven 3

Automatic Dependency Management is a feature for users who use Maven 3 and wish for their parent and child dependencies to be set up according to the dependencies in the Maven pom.xml. Every time the plan is run, the Bamboo Automatic Dependencies are updated to reflect any additions or removals of Maven dependencies.

To setup automatic dependency management:

  1. Click Dashboard and then the All Plans tab.
  2. Locate the plan in the list and click the edit icon to display the plan's configuration pages.
  3. Locate the job that contains the pom.xml you wish to use to automatically update plan dependencies by analysing a Maven pom file.
  4. Choose Actions > Configure Job.
  5. Click on the Tasks tab.
  6. 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.

    SettingNotes
    Override Project FileOptional. The location relative to the working directory or sub-working directory where the project file (pom.xml) is located.
    Working Sub DirectoryOptional. The sub directory from which the Task should look for the project file (pom.xml)
    Alternate location of settings.xmlOptional. Specify an alternate settings.xml to be used if the Task needs to resolve dependencies from specific Maven repositories.
    Path to Maven local repositoryOptional. Specify a full path to a local Maven repository for the Task to use to resolve dependencies.
  7. Click Save.
  8. Use the Plan Navigator to return to the plan.
  9. Click the Dependencies tab.
  10. Select Automatic Dependency Management. You should see the name of the job for which you configured the Maven Dependency Processor appear.
  11. Click Save.

Dependency blocking

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.

Notes

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.

  • If the child build uses the same source as the parent build (for example, the Subversion URL is the same), the child build will be forced to check out the same revision of source code as the parent build. This ensures that builds are consistent when triggering one build from another.
  • 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

  1. Anonymous

    Hmmm... 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.

  2. Anonymous

    I agree, these child and parent terms are confusing.

  3. Anonymous

    How 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?

  4. Nimitt Desai

    I 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.

    1. James Dumay

      Hi Nimitt,

      This isn't possible right now. Please raise a feature request and we can see what we can do.

      Thanks
      James 

  5. Anonymous

    I 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.

  6. jeff mease

    I 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.