We are pleased to announce the availability of the second Early Access Program (EAP) release of Bitbucket Server 7.0.
This EAP release is so that app vendors and customers who have written in-house apps can update their apps to ensure they will work with the public release of Bitbucket Server 7.0.
Important things to note about this EAP release:
- As development of the release is underway, the specifics of breaking changes will evolve and there may be other minor API changes between this release and the public release of Bitbucket Server 7.0.
- This release should not be used in production environments. For all production use and testing of Bitbucket Server, please use the latest official release instead.
Obtaining the Bitbucket Server 7.0 EAP2 release
Links to download installers and archives:
Or via the Bitbucket Server EAP Download page.
Sources are available for users with a valid Bitbucket Server license through their license details at my.atlassian.com
We need your feedback!
If you have any questions or feedback about this preview of Bitbucket Server 7.0, ask them in the Bitbucket Server category here in the Atlassian Developer Community forums, and our friendly team of developers will respond to them.
Supported platforms changes:
Added
- Git 2.25
- MS SQL Server 2019
Removal of support for deprecated databases:
- MariaDB 10.0
Removal of support for deprecated browsers:
- Internet Explorer 11
Removal of support for operating systems
- Support has been removed for running on Linux with kernel version older than 2.6.17
- Support has been removed for running on Linux with glibc version older than 2.7
Noteworthy plugin API changes since 7.0.0-eap1
Update atlassian-clientside-extensions from 0.6 to 0.9
The atlassian-clientside-extensions plugin has been updated from 0.6 to 0.9. Refer to its changelog for details
Auditing
Bitbucket Server 7.0 includes a major overhaul to how auditing works for the application. This includes an extended model for representing auditing data, new categorization metadata associated with every event, and changes to how audit events are provided and consumed by plugins.
Audit data model replacement
Prior to 7.0, audit events were represented by an AuditEntry on a Bitbucket Server AuditEvent. This has been replaced by a different AuditEvent, which is a cross-product replacement.
A legacy AuditEntry maps to a new AuditEvent as follows:
-
AuditEntry.getAction()has been replaced byAuditEvent.getAction() -
AuditEntry.getProject()andAuditEntry.getRepository()have been replaced byAuditEvent.getAffectedObjects()(where a project or a repository is represented by anAuditResource) -
AuditEntry.getDetails()andAuditEntry.getTarget()have no direct replacements, but can be represented as anAuditAttribute, which is what the system will do internally when converting fromAuditEntryintoAuditEvent(note that these are not guaranteed to be present on system events after 7.0, and associated data will likely be represented differently) -
AuditEntry.getDate(),AuditEntry.getSourceIpAddress()andAuditEntry.getUser()have no replacements, but are set automatically by the system as part of processing the event, and are part of theAuditEntityconstructed from theAuditEventasAuditEntity.getTimestamp(),AuditEntity.getSource()andAuditEntity.getAuthor()respectively
Providing audit events
Prior to 7.0, plugin developers were able to add audited events to the system by annotating an event with @Audited and implementing an AuditEntryConverter. Plugin developers could also publish a Bitbucket Server AuditEvent directly. These methods of providing auditing events have been deprecated in 7.0 for removal in 8.0. These legacy methods of providing auditing events to the system do so via the deprecated AuditEntry model. The application internally makes a best effort conversion to the new AuditEvent model, which may not result in the new model being used completely.
It is recommended that plugin developers switch to using @Auditable with an AuditEventConverter. This is the new audit event provider API added in 7.0, which is used to convert directly to the new AuditEvent model. This way plugin developers can directly construct their AuditEvent and have better control over what information is included in the audit event.
Priority
The concept of audit Priority (and the associated enum) have been deprecated in 7.0 for removal in 8.0. A Priority set on an @Audited annotation will be ignored (so all events are audited regardless of priority). From 7.0 onward, using CoverageArea and CoverageLevel (via the new @Auditable annotation) can be used to attach metadata to an event to control when it should be audited.
Channels
The concept of Channels (and the associated class) have been been deprecated in 7.0 for removal in 8.0. From 7.0 onward, AuditResource’s should be added to the affectedObjects property of the AuditEvent instead. AuditUtils has helper methods that can be used to create AuditResources for projects and repositories. Adding a project affectedObject ensures the audited event will appear in the project audit log, and adding a repository affectedObject ensures the audited event will appear in the repository audit log. Multiple affectedObjects can be added to a single AuditEvent if desired.
From 7.0 onward, a Channel set on an @Audited annotation will be automatically converted into a project and/or repository affectedObject, if the relevant entity is present on the AuditEntry. However it is recommended that plugin developers which to using @Auditable to be able to specify affectedObjects directly.
Consuming audit events
Prior to 7.0, plugin developers were able to listen to the Bitbucket Server AuditEvent and consume all auditing events raised by the system and other plugins. The application includes logging auditing to both a file and the database, but this allowed plugins to add additional consumers. From 7.0 onward, the application will no longer publish AuditEvent - it is only being retained as a deprecated provider API until 8.0.
Instead, any plugin wishing to consume audit events must switch to implementing the new AuditConsumer SPI from 7.0 onward.
Retrieving audit events
Prior to 7.0, certain repository and project audited actions were stored in the database, and could be retrieved via AuditService. This service has been deprecated in 7.0 for removal in 8.0. Instead, any plugin wishing to retrieve audit events should use AuditSearchService.





