要約

Plan branches for plans that are using Bitbucket Server or Data Center repositories are not getting automatically created when the repository is coming from an application link that's not set as PRIMARY. When you have multiple application links to different Atlassian instances of the same product (e.g. Bamboo connected to two different Bitbucket instances) one of them will be the flagged as the PRIMARY link. Plan branches for plans that are set to use repositories coming from the Bitbucket instance with the PRIMARY link are getting automatically but those coming from any other Bitbucket instance that's not set as the PRIMARY are not getting created automatically (they can be created manually though).

環境

One Bamboo instance connected to multiple Bitbucket Server or Data Center instances where at least one Bitbucket instance is a copy/clone of another e.g. Bamboo connected to Bitbucket Production and Bitbucket Staging (copy of Production).

診断

• Application links between your Bamboo and Bitbucket Server or Data Center instances are all healthy and displaying the CONNECTED status. If they are not connected or the application link status is RED then this kb article probably doesn't apply to you. To start working on fixing your application links you might want to check the Application Links Troubleshooting Guide.
• You are capable of creating plan-level, project-level or linked repositories pointing to your Bitbucket instances successfully.
• Plans connected to repositories from your Bitbucket instances can be triggered manually (those coming from the PRIMARY link should also be getting triggered automatically).
• Plan branches for plans that are set to use repositories coming from the Bitbucket instance with the PRIMARY link are getting automatically created for new branches and pull requests. You can check whether a Bitbucket instance has the PRIMARY link from the Bamboo administration > Overview > Manage apps > Application links page:
  
• Plan branches for plans that are set to use repositories coming from any other Bitbucket instance that's not set as the PRIMARY are not getting created automatically. They can be created manually but are not getting created automatically by Bamboo:
  
• With the help of the com.atlassian.bamboo.plugins.stash.events package added to the Bamboo administration > Overview > System > Log settings page in ALL (TRACE) mode we can see that Bamboo is receiving the remote events from all Bitbucket instances but is not reacting to those that are not coming from the PRIMARY Bitbucket instance.

• The remote event received from Bitbucket instances that are not PRIMARY have the wrong sourceId:

  2021-10-29 07:20:59,654 TRACE [AtlassianEvent::0-BAM::EVENTS:pool-1-thread-49] [StashDiagnostics] Recording Stash event: com.atlassian.stash.plugin.remote.event.StashPullRequestOpenedRemoteEvent@2fbd88a2[fromBranch=refs/heads/develop,fromProjectKey=GIBSON,fromRepositorySlug=firebird,id=2,toBranch=refs/heads/master,toProjectKey=GIBSON,toRepositorySlug=firebird,sourceId=805635f4-d575-33d3-9a8c-6997a1122c98,sourceUrl=http://clone7170:7990]

  In this example all of the information about the pull request that was created in the Bitbucket - Clone instance was correct (i.e. repository, branch, Bitbucket url and etc) except the sourceId. The sourceId is a unique number assigned to the application link. In the example above the sourceId is from the Bitbucket - Production instance when it should be from the cloned instance. In order to check the ID of your application links you can use the following select query inside Bamboo's database:

  select * from bandana where bandana_key like 'applinks.admin%display.url';

  You will find the application link ID under the BANDANA_KEY column in between the words applinks.admin and display.url in the results. Try to match the application ID from the instance that actually sent the remote event with what is reported by Bamboo in the logs.

原因

The cause of the problem is Server ID assigned to the copy/clone of your Bitbucket Server or Data Center instance. This usually happens when you clone an existing Bitbucket instance as the clone will end up with the same Server ID of your production instance. When the Server IDs of your Bitbucket instances are the same Bamboo sees the remote events as coming from the PRIMARY link no matter what Bitbucket instance it actually came from. You can check and confirm whether your Bitbucket instances have the same Server ID by running the following select query inside each Bitbucket instance's database:

select * from app_property;

ソリューション

Change the Server ID of the clone Bitbucket instance:

1. In order to change the Server ID of your Bitbucket instance please stop your instance. For multi-node Data Center instances, all nodes should be stopped. For further info, refer to Start and stop Bitbucket.

2. Run the following update query inside the database of your clone Bitbucket instance:

   update app_property set prop_value = '<ID>' where prop_key = 'server.id';

   Replace the <ID> in the query with a new Server ID. You can create one for yourself – just make sure to follow the format of 4 sets of 4 capitalized alpha numeric characters separated by hyphens. Example: BA8J-RYK8-ABC4-KK8N

   The query above is valid for both MySQL and PostgreSQL, you may need to update it to work with different databases.

3. Restart your Bitbucket instance. Restart all nodes for Data Center instances with multiple nodes. For further info, refer to Start and stop Bitbucket.