feat(platform/bitbucket): add support for Bitbucket development branching model

[setchy]

Changes

Continuation of #20803

Updates the Bitbucket Cloud repository initialization logic to fetch and set the development branch name instead of relying only on the main branch name.

Context

Closes #20802

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[setchy]

If memory serves correctly, there was one unresolved discussion @viceice @rarkins around should the Repository Configuration be read from

1. main branch
2. development branch

Having slept on it, I'm thinking that we keep the implementation as is and read from the "development branch" as configured by the repository's branching model configuration.

In a git-flow workflow, the "development branch" feels like the right place for the configuration to be pulled from since it is the "integration" branch. The "main branch" is mainly focused on keeping a record of the production releases as they occur

[rarkins]

So this takes up an extra API call per repo during initialization, even if the repo doesn't have the development branching model and/or uses main?

[viceice]

So this takes up an extra API call per repo during initialization, even if the repo doesn't have the development branching model and/or uses main?

only if the new config flag is enabled

[rarkins]

So this takes up an extra API call per repo during initialization, even if the repo doesn't have the development branching model and/or uses main?

only if the new config flag is enabled

I know, but I suspect most users will enable this and we'll probably switch to having it on by default in a future major release. It's a pity we can't get it with one API call but 2 isn't so bad.

[setchy]

So this takes up an extra API call per repo during initialization, even if the repo doesn't have the development branching model and/or uses main?

Unfortunately yes... I did go back and forth with Atlassian Support Engineers earlier this week to see if it was possible to retrieve this via a single API call, but no luck.

I did consider using the override_settings response values from 2.0/repositories/{{repoName}}, but it got complicated quickly and didn't really solve the problem.

 "override_settings": {
    "default_merge_strategy": true,
    "branching_model": true
}

If the repository has disabled inherit settings, then the response will contain branching_model: false, which is a signal that the repository may have a development branch configured different to main branch (but not a guarantee)

However, if inherit settings is left enabled, which is the default, then we still don't know what the Bitbucket Project branching model settings are unless we make a separate call to the Projects API, or to the Repository Branching Model API as we're doing in this PR.

Unfortunately, the two API calls aren't avoidable.

[renovate-release]

🎉 This PR is included in version 35.2.0 🎉

The release is available on:

• GitHub release
• 35.2.0

Your semantic-release bot 📦🚀