Bamboo 6.2 EAP Release Notes

Bamboo 6.2 Release Notes

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

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.

Important

Development releases are snapshots of the ongoing Bamboo development process. For that reason:

  • While we try to keep these releases stable, they have not undergone the same degree of testing as a full release.
  • Features in development releases may be incomplete, or may change or be removed before the next full release.

Much as you are able to upgrade previous versions of Bamboo to the 6.2 EAP version, and smoothly upgrade from the 6.2 EAP to the final version, once it's released, we don't recommend installing the EAP release on your current production environment. For information about the supported upgrade paths, see Bamboo upgrade guide.

Atlassian does not provide support  for development releases.

On this page:



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.

The project list, together with projects details, is available to everyone, who has access to this Bamboo instance including anonymous users when the anonymous access is enabled. 





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.

AMAZON S3
Artifacts are stored at Amazon S3 and are downloadable from there. Amazon S3 that offers unlimited flexible storage capacity. For more information about S3, see the Amazon S3 page. You can use the AWS credentials provided in the Elastic Bamboo configuration or you can configure separate account. In either case, you need to provide a bucket name. You can also (optionally) provide a root path for all the artifacts, which can come in handy if you use the same S3 bucket for other purposes. Lastly, you can define a maximum number of files per artifact; if this threshold is exceeded the artifact is automatically zipped into a single file, which reduces the number of requests to S3 when uploading and downloading the artifacts and improves the efficiency of the whole process.
SERVER-LOCAL ARTIFACT HANDLER

This handler stores the artifacts directly on Bamboo server's filesystem. It is used by Bamboo server itself and by local agents.


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.





Last modified on Dec 20, 2017

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.