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:
- 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
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.
AuditEntry maps to a new
AuditEvent as follows:
AuditEntry.getAction()has been replaced by
AuditEntry.getRepository()have been replaced by
AuditEvent.getAffectedObjects()(where a project or a repository is represented by an
AuditEntry.getTarget()have no direct replacements, but can be represented as an
AuditAttribute, which is what the system will do internally when converting from
AuditEvent(note that these are not guaranteed to be present on system events after 7.0, and associated data will likely be represented differently)
AuditEntry.getUser()have no replacements, but are set automatically by the system as part of processing the event, and are part of the
AuditEntityconstructed from the
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.
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
CoverageLevel (via the new
@Auditable annotation) can be used to attach metadata to an event to control when it should be audited.
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
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
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