/
How to create plans that run a sequence of other plans

How to create plans that run a sequence of other plans

Owned by Former user (Deleted)
Oct 30, 2019

Description

For complex build processes that entail multiple steps (both automatic and manual), often it is good practice to subset the build into sub-builds that handle more specific responsibilities and can be defined and tracked separately. This enables the entire process to be automated while making it easier to maintain and debug individual builds. More importantly, allowing good retry capabilities that smaller scale the the larger process. 

The Bamboo CLI queueBuild advanced support enables such a plan to be constructed easily using Plan Creation Scripting and the CLI runFromList support.

The same technique can also be used to kick off builds on other Bamboo servers if you run multiple Bamboo servers.

We use techniques like this to build and release the Appfire Command Line Interface (CLI) to automate our release process that involves many steps and deliverables including artifact building, testing, documentation construction and uploads, deployments, and release uploads. 

Example

-a createPlan   --plan MYPROJECT-MYPLAN --replace

... (other plan level definitions like triggers or similar)

# Queue other plans
-a runFromList --plan @plan@ \
                   --list  "BUILD1,   BUILD2,  BUILD3,   BUILD4,   BUILD5" \
                   --list2 ",         ,        --manual  --manual, ,     " \
                   --common "--plan @plan@" \
                   \
                   --input "-a addStage --stage @entry@ @entry2@" \
                   --input "-a addJob --stage @entry@ --job @entry@" \
                   --input "-a removeTask --job @entry@ --task @all" \
                   --input " \
                       -a addTask --job @entry@ --taskKey SCRIPT --description ""queue @entry@ wait"" \
                                  --field scriptLocation=INLINE \
                                  --field ""scriptBody = \
                                      acli.sh ${bamboo.localSite} -a queueBuild --wait \
                                          --plan MYPROJECT-@entry@ \
                                          --field started=${bamboo.planKey} \
                                          --field state=SUCCESSFUL \
                                  "" \
                   "

Notes

ActionDescription
listThe first list is a list of builds that will be run. In this example, the project is the same for all the builds, so we just use the plan key in the list. Otherwise, include the project key in the name and adjust the script below to not reference the project.
list2Most complex processes need some manual decision points and stages. The second list controls whether the stage is automatic (blank entry) or manual (using the --manual parameter on the stage definition).
addStage, addJobEach build is going to be kicked-off using its own stage with a single job.
removeTaskOptional and only needed if the plan has a repository defined for some other reason. The script task does not need to clone the repository and this removes the clone task that gets automatically added to jobs in plans that have a repository.
addTask

We use a script task to run the CLI action to queue the build. If you have Run CLI Actions in Bamboo you could modify this to use Bamboo CLI task instead of a script task.

  • This assumes you have an appropriate acli.sh start script (on your path) and configuration suitable for accessing your build servers (see Getting Started with Configuration for Mac and Linux or similar).
  • Either hard code your build server name defined in your acli configuration or use a standard practice to refer to a global Bamboo variable that defines the local bamboo server. In this example, variable is named localSite.
  • Note we use the wait parameter so the entire process is sequential and the results of the queued build are returned to the main build.
--filed started=...

This uses the advanced queueBuild feature that understands the status of the independent plan and whether or not it needs to be queued again based on if the plan was successfully run (likely with retries!!!) AFTER the main plan was started.

  • This is a common technique for complex processes to take a long time to complete and may have glitches that need to be handled without having to start the process from the very beginning. Especially when debugging your complex process automation.  

Recommend CLI 8.7 or higher. Older 7.x and 8.x releases support the similar capability with some minor modifications.

Related content