Bamboo YAML specs: use shared credentials with bitbucket server repository

[pBogey]

Hi, I'm using bamboo YAML specs. In the repositories config I have defined some repos as bitbucket server repos, which seem to require ssh public and private key for authentication, as per the docs.

Anyway, there is also the possibility to create SSH shared credentials at project level and reuse in all the plans: 

https://confluence.atlassian.com/bamboo/shared-credentials-424313357.html

I have tried to use this with the bitbucket server type repo in YAML specs and it doesn't seem to work. I get an error like this:

Bamboo YAML import failed: Document structure is incorrect: Found following unused properties: repositories / [1] / {repoName} / shared-credentials.
Every property must have a correct key recognizable by Bamboo and must be used as part of the configuration in the current YAML document. Common sources of these problems are typos in properties keys, unused jobs, and mixing a plan and its permissions configuration in one YAML document.

The config looked something like this:

repositories:
  - repoName:
      type: bitbucket-server
      server: BitbucketServer
      project: ProjectName
      slug: repoName
      clone-url: ssh://git@bitbucket.com/project/repo.git
      branch: ${bamboo.repoName_branch}
      viewer: com.atlassian.bamboo.plugins.stash.atlassian-bamboo-plugin-stash:bbServerViewer
      shared-credentials:
        name: SharedUserCreds
        scope: project

In order to make it work, I had to configure it like this:

repositories:
  - repoName:
      type: git
      url: ssh://git@bitbucket.com/project/repo.git
      branch: ${bamboo.repoName_branch}
      shared-credentials:
        name: SharedUserCreds
        scope: project
      viewer:
        com.atlassian.bamboo.webRepositoryViewer.stash:stashRepositoryViewer:
          webRepository.stash:
            project: ProjectName
            repositoryName: repoName
            url: https://bitbucket.com

Notice the legacy Stash viewer used, because git repos do not support bbServerViewer.

I don't understand why I could use the shared credentials for a plain git repo, but not for the bitbucket server type of repo. It doesn't make sense, am I missing something or is this a real limitation?

I am defining repositories like this and not using linked repos, because I want to be able to override the branch with custom runs (https://jira.atlassian.com/browse/BAM-21066).

[Eduardo Collaziol · Accepted solution]

Hello! Thank you for reaching out to Atlassian Community!

We understand you're using Bamboo YAML specs to manage your plans, and would like to use Shared Credentials when configuring Bitbucket Data Center repositories' SSH keys.

Application links

The integration between Bamboo and Bitbucket Data Center is done through application links, which automatically connect the repositories and setups the SSH keys for you when adding the repository through the User Interface:

• Integrating Bamboo with Bitbucket Data Center – Bamboo Data Center 10.2 – Atlassian Documentation

When using the Bitbucket Server repository type, the process is entirely done through the application link, and shared credentials cannot be used – although this might sound like a limitation, the process is done through the application link to provide several integration features that are not available with other repository types:

• Automated Builds: Bitbucket Data Center can trigger builds in Bamboo automatically when changes are made to the repository code.

• Branch Synchronization: It keeps Bamboo plan branches updated with changes in Bitbucket repository branches.

• Commit and Build Visibility: Commits in Bitbucket are visible in their related Bamboo builds, and build results and their statuses are automatically sent back to Bitbucket.

• Pull Request: Bamboo can automatically create plan branches for pull requests.

• Other features: the app link integration allows for detailed build information (e.g., test summaries and logs), to be accessible directly from the Bitbucket UI.

As you mentioned setting up SSH keys in the YAML configuration, if you have previously configured the repository in the UI as a Linked Repository or as a Project level repository, you can directly reference them in your plan configuration without having to define it again:

• Referring linked repositories 

While the plain Git repository type does offer the ability to use SSH credentials, it also lacks the integration features that the Bitbucket Server repository type provides.

Override branches

Since you're creating the repositories at a Plan Level to be able to override branches in YAML, you can alternatively setup SSH keys for system use in Bitbucket and re-use them across your YAML plans.

• YAML anchors 
• YAML includes

We hope this helps clarify your queries!

Thank you!

[pBogey]

Thanks for the answer. Man, I swear all my issues are coming from not being able to change the repository branches on the fly.

Imagine having 2 repositories defined in the plan and they are dependent.

You are not able to override any of the branch without a pull request. So you create feature_branch_A in repo_A and feature_branch_B in repo_B. You update the plan specs in your main repo (say repo_A) to point to feature_branch_B for repo_B.

You run the CI and validate the changes. All is good and you can merge the PR in repo_B, but now you need to make another commit in repo_A to change back the branch (default branch) for repo_B in the plan specs.

You need to run the CI again, but in the meantime, all your colleagues plans will fail, because repo_B has been updated, while repo_A has not.

If another colleague was working on repo_B and had a merged PR before you merged repo_A, not you are potentially in a deadlock, because two incompatible changes have been merged in repo_B, while still having two PRs in repo_A, that cannot be merged because another commit was necessary to update the specs.

After updating the specs in both PRs on repo_A, now the CI will fail for both of them because neither of them has the complete changes to work with repo_B.

That's why I'm using bamboo_variables to be able to change the branch of repo_b on the fly with a custom build.