Changes for Bamboo 2.7
Bamboo 2.7 involves the introduction of Staged Builds. Each Plan contains one or many stages, and each stage contains one or many Jobs. This has involved significant back-end changes to accommodate this feature. A Build used to be the core object of Bamboo. This class is now deprecated and in its place are the Chain and the Job. The functionality of the Build class has been split between these two classes and what the users now see as a "Plan" in the UI is represented by the Chain class.
Logical Break Up Of Responsibilities During The Build:
Source Repository For Change Detection
Source Repository For Checkout
You will notice in the above table that there is a repository configured for the Chain level and for the Job. The Chain's repository is used for build triggering and reporting included changes for the Chain result. The Job's repository is used for checking out the source code and reporting included changes for the job result. To make maintenance of your plans easier, you can set up your jobs to inherit the repository of the chain, however, this should be transparent to your plugins.
Both the Chain and the Job extend the Plan interface and share the one database table. There have also been two common interfaces introduced to help deal with commonalities between the implementations (TopLevelPlan and Buildable). As the Build class has now been deprecated most of Bamboo's internals have been updated, this includes managers and our plugin interfaces. Each case is different, but you will find some methods now deal with Plan, TopLevelPlan or Buildable, others will deal directly with the Chain or Job, whilst others will happily deal with all 5, you just have to tell it which one your after. When developing your plugin, if you are passed a common interface, you will need to ensure that the operation you wish to perform is actually applicable to the specific implementation.
Jobs are grouped in a Chain by ChainStages. ChainStages have a specific order inside the Chain, whilst Jobs inside a ChainStages do not have any order. The diagrams below shows the relationships and hierarchy of the new classes (The Build object has been included in the diagram to help explanation)
As jobs are a child of the chain, the identification key of the job also includes the full key of the chain. For example, a chain is represented by "BAMBOO-TRUNK" whilst the job is "BAMBOO-TRUNK-UNITTESTS".
The structure of result objects follows the same pattern as the plans. ChainResultSummary and BuildResultsSummary (Job) share the common interface ResultsSummary. Job results are grouped by ChainStageResult.
The New Build Process
If any required functionality can not be found on the replacement classes please let us know.
There is no replacement for this, however the various implementations of the PlanCreationService may provide the required functionality
This class has been deprecated since 2.6. However, in 2.7 there is a new interface to access the few last bits an pieces left stored in these files. Specifically the ExtraBuildResultsData class provides you with the build return code and any build errors. The only reason to go to the BuildResults now, should be to get specific successful test results. The ExtraBuildResultsData is accessible via BuildResultsSummary.getExtraBuildResultsData()
use the CustomBuildCompleteAction interface directly.
use the PlanKeys class instead
There is no replacement for this, however the various implementations of the PlanCreationService or the PlanValidationService may provide the required functionality.http://docs.atlassian.com/atlassian-bamboo/latest/com/atlassian/bamboo/caching/DashboardCachingManager.html#getAllTopLevelPlans()
Build resource is replaced by Result resource.
build resource has been deprecated, however is still operational.
All new queries should use
/result resource instead. Syntax remains the same.
Currently running builds are available by REST
Runtime information for running builds is available via REST now. Not all result information is available while the build is running (for example, testResults information) so can not be returned in the REST response . You will however be able to retrieve other valuable information such as progress of the build, commits and build logs (for Jobs only)
Chain result example:
Job result example
REST reflects internal structure of chains and jobs.
New expand points have been added for querying chain structure.
Job key support
REST honours new key scheme, so Chain keys and Job keys may be used to address proper entity.
isInBuildQueue attribute of RestPlan has been replaced with isActive
Can now pass in plan type to many different queries.
May be applied to all queries that list plans and results, so
Test results information is available only for Job level results.
Chain results contain only statistical test results information, so there is no testResults expand point.
May be applied to any Job result or chain result if properly expanded (for Chains it should be prefixed by stages.stage.results.result. )
Only one category of test results can be expanded at a time.
Plan Configuration Changes
In 2.7 Bamboo has lost its Plan Creation Wizard. It now has a shortened one page form to create a new Plan. Plugin configuration (except for Builders and Repositories) will not be available at creation time. This should hopefully make writing these plugins easier as you no longer have to deal with both ways of creating configuration and there will always be a BuildDefinition and Plan object available to you.
Also, the view of the plan configuration has also been reformatted to a simplified one-page view. We encourage plugins, to limit the amount of space their view configuration takes up. And, if possible do not show anything if the plugin is not enabled (as opposed to showing "feature X is disabled")
There is also now a new tab on both the Plan and Job Configuration available for plugin developers to put their plugin configuration - the "Miscellaneous" tab. To make use of this tab, use the Additional Build Configuration Plugin point and/or ensure you plugin class implements MiscellaneousBuildConfigurationPlugin interface. You will notice that this interface actually provides you with the method isApplicableTo(plan). This method allows you to decide whether you plugin applies to Plans or Jobs or both.
To allow for the condensed creation page there is a new type of template (optional) on the Repository interface. This allows the UI to show the minimum required configuration on the creation page whilst allowing more advanced configuration after creating the initial plan. If you are extending AbstractRepository, you can just provide the new template type in your plugin definition (see the example below). If you don't supply the minimal template, the normal edit template will be used. If implementing the Repository interface directly you will need to implement the getMinimalEditHtml() method.
Method Signature Changes
Base Configurable Plugin, Build Configuration Aware Plugin
Most plugin points which allow you to display content in Bamboo's UI, provide you with a getEditHtml() method to implement. Many have base implementations inside Bamboo, so it may not effect you. But, if you have specifically implemented/overridden this method in your plugin you will need to ensure that it properly handles a null plan argument
Build Complete Action Module
The CustomBuildCompleteAction interface has been updated to take in a Buildable instead of a Build inline with the new plan class hierarchy. However we actually suggest you move away from using this plugin point (it can be prone to thread safety problems) and instead use the http://docs.atlassian.com/atlassian-bamboo/latest/com/atlassian/bamboo/build/CustomPostBuildCompletedAction.htmlPost-Build Completed Action Module or the Build Processor Server Module.
The TriggerReason interface (Trigger Reason Module) has been updated to take in a ResultsSummary instead of a BuildResultsSummary. You will need to ensure any implementations of this will work with both Chains and Jobs. Also, it should be noted that Jobs do not have their own Trigger Reason, they will inherit the trigger reason of their parent.
Web Repository Module
Notification Type can now be scoped to determine where it can be configured. There are three options (though poorly named):
Chain- For Plan level notifications
Plan- for Job level notifications
System- for global notifications (configured in the administration section of Bamboo)
If you don't provide a scope, it will default to a Job level notification. Also, note that whilst there are Job and Plan level notifications, they are both configured at the plan level. Job notifications will generally apply to all jobs within the Plan.