Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-22031

Support the use of variables when setting branch names for Bitbucket Server and Data Center repositories from the UI and Bamboo Specs

XMLWordPrintable

    • 6
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Issue Summary

      This affects Data Center:

      It would be nice if we could fully support the use of variables when setting branch names for Bitbucket Server and Data Center repositories from the UI and Bamboo Specs. Currently, it's impossible to use variables to set branch names from the UI; however it is possible to bypass this limitation using Bamboo Specs.

      IMPORTANT

      Just because you can use Bamboo Specs to work with variables instead of branch names for Bitbucket Server and Data Center repositories, it doesn't mean the feature is working as expected. The problem with using Bamboo Specs to work around the limitation imposed by the Bamboo UI is that the variable breaks some of the functionalities provided by the Bitbucket Server and Data Center integration.

      So far we have had reports of the following features not working as expected when using variables to set branch names for Bitbucket Server and Data Center repositories:

      • The Bitbucket Server and Data Center repository trigger not working for the plans using the variable;
      • Bamboo reporting the variable as the branch name when notifying Bitbucket Server and Data Center about build statuses instead of the actual branch name.
        • For example, rather than saying branch develop was built by Bamboo on PROJ-PLAN-2, Bamboo reports the variable as the branch name e.g. ${bamboo.CUSTOM_BRANCH}. Since there's no branch in the repository with such a name, Bitbucket doesn't associate that Bamboo build with the repository branch, making it impossible for users to find builds associated with that branch inside Bitbucket.

      In short, we don't recommend using variables to set branch names for Bitbucket Server and Data Center repositories via Bamboo Specs and bypass the limitation imposed by the Bamboo UI until the feature is fully supported, as it can break things/ yield unexpected results. If you choose to do so, remember that not all features will work as intended.

      Steps to Reproduce

      We'll use an example to demonstrate how to work around the limitation imposed by the Bamboo UI and set a branch name using a variable for a Bitbucket Server and Data Center repository via Bamboo Specs.

      1. In this example, the plan has two repositories associated with it.
        • The first repository is a linked repository containing the Specs code for the plan.
        • The second repository is a plan repository containing some code that needs to be tested – this is the repository we're going to set the variable.
          Example
          ...
          variables:
            CUSTOM_BRANCH: main
          Default Job:
            key: JOB1
            tasks:
            - checkout:
                repository: specs-repo
                path: specs-repo
                force-clean-build: 'true'
                description: Checkout Default Repository
            - checkout:
                repository: plan_repo
                path: plan_repo
                force-clean-build: 'true'
                description: Checkout Local Repository
            artifact-subscriptions: []
          repositories:
          - specs_repo:
              scope: global
          - plan_repo:
              type: bitbucket-server
              server: Bitbucket
              project: PROJECT
              slug: rainbow
              clone-url: ssh://git@linux-29478.prod.atl-cd.net:7999/project/rainbow.git
              public-key: ssh-rsa AAAAB3N...
              private-key: BAMSCRT@0@0@...
              branch: ${bamboo.CUSTOM_BRANCH}
              command-timeout-minutes: '180'
              use-shallow-clones: 'false'
              cache-on-agents: 'true'
              submodules: 'false'
              verbose-logs: 'false'
              fetch-all: 'false'
              lfs: 'false'
              viewer: com.atlassian.bamboo.plugins.stash.atlassian-bamboo-plugin-stash:bbServerViewer
          branches:
          ...
          

          First, we need to declare the CUSTOM_BRANCH variable and set the branch name. Then call the variable using ${bamboo.CUSTOM_BRANCH} from the branch attribute inside the plan repository configuration.

      2. This allows us to override the branch we will build for the plan repository using the UI's Run > Run customized... option.

      Expected Results

      1. It is possible to override the branch for a certain build using the Run > Run customized... option with no side effects.
      2. Changes made to the branch that was set inside the Specs file (in this case, main) trigger a build if there's a "Bitbucket Server repository triggered" trigger set for the repository.

      Actual Results

      1. It is possible to override the branch for a certain build using the Run > Run customized... option ; however we get two builds triggered one after the other. The first build checks out the branch that was modified using the Run > Run customized… option, and the second build triggered immediately afterward will check out the branch that was defined inside the YAML file (using the variable).
      2. Bamboo doesn't automatically trigger builds when there's a change in the repository using the variable even if the "Bitbucket Server repository triggered" trigger is enabled for that repository.
        • If you remove the variable and use an actual branch name, your changes will start getting automatically built by Bamboo again.

      Workaround

      Bamboo versions >= 9.0.0

      There's a workaround to the first problem described above (under Actual Results):

      • Remove the "Bitbucket Server repository triggered" trigger for the plan repository (not the linked repository).

      We're getting two builds triggered one after the other because the plan repository uses the "Bitbucket Server repository triggered" trigger. Since we're working with variables on the plan repository, this trigger won't work anyway (as mentioned above), so it's safe to remove it. We no longer get duplicate builds after removing the trigger for the plan repository (there's no need to disable the trigger for the linked repository, though, only the plan repository).

            Unassigned Unassigned
            brosa Bruno Rosa
            Votes:
            7 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: