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 fromAuditEntry
intoAuditEvent
(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 theAuditEntity
constructed from theAuditEvent
asAuditEntity.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 AuditResource
s 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 affectedObject
s 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 affectedObject
s 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
.