We are proud to present Bamboo 6.2 EAP . This release is part of our Early Access Program (EAP) leading up to the official  Bamboo 6.2 release. We are making these EAP milestones publicly available so that developers can start assessing the impact of the changes that we are making.

Changes to permissions 

Bamboo 6.2 introduces multiple changes to permissions to make permissions management more transparent. Here's a summary of these changes:

Project admin

We've created a new permission called Project admin allows Bamboo administrators to hand down some of their responsibilities for more effective management of the project. For instance, if Bamboo is used by 10 development teams, a global administrator can create 10 projects, one for each team, and delegate permissions management to team leaders by giving them the Project admin permissions.  Users with the Project admin permissions can:

• manage permissions for the project
• manage permissions for all plans in a project
• change project settings

Create plan permission

The former "Create plan" global permission, now called Create, allows you to also create empty projects. Additionally, having the Create plan permission on a project-level already allows you to create new plans for that project even if you don't have the the global Create"permission.

The already existing plan-level permissions (View, Edit, Build, Close, Admin) can now also be set on a project-level, which means that you will have them in all plans in your project. You can still set these permissions on the plan-level only just like before.

Permissions become additive

Once you’re assigned permissions on any level, you'll automatically have permissions on lower levels. You can’t override or remove permissions on lower levels. For example, if you have Create permission of a global level, you can create plans on all levels. Another example, if you have Build permission assigned to you on a project level and none assigned on the plan level explicitly, you will still have build permissions for that plan anyhow.

Projects menu

The new Projects menu lists all available projects together with their project codes, names and descriptions.

Artifact handlers

With Bamboo 6.2 artifact handlers Bamboo administrators can control where artifacts produced by plans are stored. This can help to optimize the utilization of network bandwith and filesystem space. You can activate each handler for shared and non-shared artifacts separately. The default artifact handler selection is configured by Bamboo administrator but can be overridden in a plan's configuration by users that have administration permission on the plan.

To configure artifact handlers, go to Administration > Artifact handlers.

Types of handlers used by  Bamboo:

AGENT-LOCAL ARTIFACT HANDLER

This handlers stores the artifact on Bamboo's remote agent's filesystem.  This handler does not publish artifacts to server (in other words, the artifacts will not be downloadable from result pages if remote or s3 handlers are not enabled). It can be used to save bandwidth when exchanging artifacts between builds & deployments running on the same agent or running on different agents that share common filesystem. In the configuration you need to define the root directory in which all the artifacts will be saved.

BAMBOO REMOTE HANDLER 

This handler makes artifacts accessible on Bamboo remote and elastic agents. It also allows remote agents to publish artifacts they produce when running builds.

Repository-stored Bamboo Specs

6.2 release of Bamboo brings you possibility of storing your build plan configuration (Bamboo Specs) in your Bitbucket repository. Storing Bamboo Specs in a repository gives you access to history of plan specification, and makes it easy to revert to a particular moment in time. Additionally, by storing plans in repository users have not only information what changes were applied in the past, but also why they have been implemented this way giving them more context about the changes.

To allow Bamboo to scan a repository for Bamboo Specs, go to Administration > Linked repositories. In the Bamboo Specs tab, toggle Scan for Bamboo Specs.

We've also added a new icon to the  build history to help you identify the Bamboo Specs errors.

Support for Bitbucket Server Smart Mirroring

Bamboo introduces support for the Bitbucket Server Smart Mirroring capability. Smart Mirroring allows you to use mirror locations for storing your repository data instead of using remote location. This way you can clone and fetch repositories from the mirror and get identical content, only faster.

Read more about all benefits of using Smart Mirroring in the Bitbucket Server documentation.

On Bamboo side, repository can be cloned from a selected mirror. Bamboo can also use mirrors for triggering builds. Whenever a mirror is synchronized with new changes, it sends an event to Bamboo and activates triggers on the affected repository.

Requirements:

• Bitbucket Server 5.0.0 or later
• Bitbucket Server Data Center license to support mirrors
• Routing from Bamboo to Stash and a selected mirror enabled.
• Routing between agent and mirror enabled.

Downgrading from Bitbucket Server Data Center license to a regular license may cause problems. In the unlikely event of such a downgrade, we recommend to switch all repositories to primary before switching versions.

Downgrading from Bitbucket Server Data Center from version 5+ to version 4 may cause problems. In the unlikely event of such a downgrade, we recommend to switch all repositories to primary before switching versions.