Bitbucket Server 5.0 release notes
2017 年 5 月 2 日
If you are upgrading from an earlier version, check the Bitbucket Server upgrade guide. Also, be sure to see the End of support announcements and the changes listed in the API changelog.
The Bitbucket 5.0 changelog is at the bottom of this page.
Committer verification
Git and distributed version control have many benefits out of the box, but controlling access and workflows isn't one of them. For example, without a Git management tool a developer can push commits that others have written to the central repository. This creates problems for organizations with strict security and compliance requirements. Bitbucket lets you address this through permissions and workflow controls including Git hooks. In 5.0, we've added a new committer verification hook, which enforces that only the author of a commit can push those changes back to Bitbucket Server or Data Center. Now you can sleep easy knowing that only authorized code changes can make it to your repositories.
The committer verification hook in the repository settings in Bitbucket Server & Data Center 5.0
Smart mirroring gets smarter
Smart mirroring in Bitbucket Data Center is a hassle-free way of providing geographically dispersed teams a read-only copy of the repository. By pulling updates from a local mirror, teams can avoid the pain of high-latency and low-bandwidth clone operations. All authentication, permissions, and updates are controlled by the master data center instance keeping admin maintenance to a minimum.
In Bitbucket Data Center 5.0 we're introducing authentication caching - a way for end users to maintain mirror access even in the event of short outages. Instead of communicating to the main server for every login event, credentials are now cached on the mirror for 5 minutes at a time. If network connection is patchy or the main server is offline, users can still fetch/clone using the cached credentials. You can rest easy knowing that Bitbucket Data Center's active-active clustering, disaster recovery, and now authentication caching ensures your code will always be available. This feature is enabled by default for all mirror types - both bitbucket.org mirrors and Bitbucket Server mirrors - and for HTTP basic and SSH auth methods. You can configure these caches within the bitbucket.properties file.
Improved integrations in Bitbucket Server
Traditionally the link between JIRA Software and Bitbucket has been on the commit level (i.e. commit A pertains to JIRA issue ABC-123). In Bitbucket Server 5.0 we're adding repository level shortcuts allowing teams to connect a repository to any related asset, like a JIRA Project. Repository shortcuts make it easy for everyone on the team to find and jump to repository information. Simply link to your JIRA board, Confluence space, Bamboo plans, HipChat room, or whatever else that's important to you. Adding a shortcut to your repo is simple, have a look at the page Add a shortcut link to a repository for details.
Check out repository shortcuts in action
Tighter integrations between Bitbucket Server and Bamboo
Bamboo's integration with Bitbucket Server is also getting an upgrade. Currently we display build status (e.g. pass/fail) on related commits, branches, and pull requests in Bitbucket Server, but teams were unable to see Bamboo builds in-progress or trigger builds on pull request creation. With the addition of in-progress build status and pull request aware builds in Bamboo, developers gain more control over when their builds kick off and can monitor progress from inside Bitbucket. This frees up Bamboo build agent resources and cuts down on unnecessary build noise. Even better, if you're not using plan branches already, now you can, and know that every pull request will get built. For more information on all of the Bitbucket Server and Bamboo integration enhancements, check out our integration guides.
Configuring plan branches to build on the creation of a Bitbucket Server pull request in Bamboo 6.0
There's always room for a bit more fun at work...
Productivity at scale isn't all integrations and workflow. In Bitbucket Server & Data Center 5.0, let your team know how you really feel with emoji and HipChat emoticon support for comments. To look for the perfect emoji type " : " which brings up the list of available options.
Customizations to Bitbucket's server.xml file must be migrated to bitbucket.properties
Since Stash 3.8, the Tomcat server.xml configuration file has survived upgrades. With Bitbucket Server 5.0, we're moving from a webapp that can be deployed into any container (with Tomcat being the one we ship) to a Spring Boot application which starts its own container.
This changes where you configure properties such as port numbers, context paths, and access protocol (among other things) to centralize custom configuration to a single directory and file, to make upgrading easier for future releases. Due to the complexity of the server.xml file, we will not automatically migrate settings stored there. Admins that have modified the server.xml file will need to manually edit their bitbucket.properties file when upgrading to 5.0+.
To upgrade to Bitbucket Server 5+, you must migrate customizations to bitbucket.properties
Be sure to carefully read the Bitbucket Server upgrade guide to determine what impact this change may have on your instance. The page Migrate server.xml customizations to bitbucket.properties has specifics on which properties need to be migrated, how to migrate them, and includes some examples that demonstrate how to migrate some common customizations.
環境変数
Bitbucket Server requires some environment variables be set when starting (e.g. BITBUCKET_HOME) and also supports some optional variables (e.g. JVM_MAXIMUM_MEMORY & JVM_SUPPORT_RECOMMENDED_ARGS). Prior to Bitbucket Server 5.0, support for consuming these variables from the callers environment was inconsistent.
Some could only be set in the startup scripts, while others would be only be honored in specific circumstances. For example if BITBUCKET_USER was not the same as the user calling the start script, while switching user these environment variables would be dropped.
In Bitbucket Server 5.0 we now honor these environment variables when declared in the caller's the environment at the time the start/stop scripts are called:
BITBUCKET_HOME
BITBUCKET_USER
JAVA_KEYSTORE
JAVA_KEYSTORE_PASSWORD
JAVA_TRUSTSTORE
JMX_PASSWORD_FILE
JMX_REMOTE_AUTH
JMX_REMOTE_PORT
JRE_HOME
JVM_MAXIMUM_MEMORY
JVM_MINIMUM_MEMORY
JVM_SUPPORT_RECOMMENDED_ARGS
RMI_SERVER_HOSTNAMEStart script changes
In Bitbucket Server 5.0, some startup scripts have had their name prefixed with an underscore. These scripts have been deprecated, and you should no longer call these scripts directly. This is to avoid confusion, because previously there were multiple start and stop scripts, making it easy to confuse which one to call. Now, there is only one script, that begins with "start" and one that begins with "stop".
For example, have a look at the differences between the scripts you would run to start and stop Bitbucket without the bundled Elasticsearch.
| Bitbucket Server 4.14 | Bitbucket Server 5.0 |
|---|---|
Linux
Windows
|
Linux
Windows
|
It's especially important to know this if you use any scripts to automate starting or stopping Bitbucket Server or Data Center, because in order to continue using those scripts with Bitbucket Server or Data Center 5.0 you will need to update your scripts.
Removal of setenv.sh & setenv.bat
The setenv.sh file was significant in Bitbucket Server 4.x as it was the site where tuning a number of environment variables was required. The following table summarises the old and new locations for the thirteen key environment variables:
環境変数 | Old (4.14) | New (5.0) |
|---|---|---|
BITBUCKET_HOME | set-bitbucket-home.sh (Linux/Mac) | set-bitbucket-home.sh (Linux/Mac) |
BITBUCKET_USER | set-bitbucket-user.sh (Linux/Mac) | set-bitbucket-user.sh (Linux/Mac) |
JRE_HOME | No placeholder in startup scripts | No placeholder in startup scripts |
JVM_MINIMUM_MEMORY | setenv.sh (Linux/Mac) | _start-webapp.sh (Linux/Mac) |
JVM_SUPPORT_RECOMMENDED_ARGS | setenv.sh (Linux/Mac) | _start-webapp.sh (Linux/Mac) |
JAVA_KEYSTORE | setenv.sh (Linux/Mac) | set-jmx-opts.sh (Linux/Mac) |
Bitbucket Server 5+ no long supports AJP connections
Starting from version 5.0, Bitbucket Server does not support reverse proxies using AJP connections. While never officially supported, previous versions of Bitbucket Server could use AJP connections. However, with changes to how Bitbucket Server uses Tomcat, using AJP connections with Bitbucket Server (or Data Center) 5.0+ will cause the application to fail on startup.
Changelog
This section will contain information about the Bitbucket Server 5.0 minor releases as they become available. These releases will be free to all customers with active Bitbucket Server software maintenance.
If you are upgrading from an earlier version of Bitbucket Server, check the Bitbucket Server upgrade guide.
The issues listed below are the highlights of all those that have been resolved for the Bitbucket Server 5.0.x releases, and are ordered by votes received.