Summary

      If a Trigger is enabled, Change Detection runs after a build and tries to trigger a new build with any changes (BAM-18497). With customized builds (Run >> Run Customized), users have the option to run off of custom commit hashes, which may be on different branches. In these cases, Bamboo will not be able to download the changes and run the build.

      Steps to Reproduce

      1. Add a branch more_tests to a build
      2. Configure a variable for the branch name (BRANCH_NAME)
      3. Add a trigger on the repository
      4. Do not merge more_tests to master
      5. Run a custom build using the more_tests branch

      Expected Results

      Build runs as expected

      Actual Results

      • A build ran as expected using the latest changeset on more_tests; but
      • Immediately after the build, change detection finds the delta between the revision used in the custom build and the latest revision on the master branch and triggers a new build

      The following appears in the Commits tab:

      [unknown]
      Bamboo was unable to extract changes between revision <more_tests_commit_hash> and <master_commit_hash>.

      Workaround

      Remove any Triggers from the build

            [BAM-18527] Do not run Change Detection after customized run

            Better workaround: 

             

            1. Set your Change Detection Options to "only changes that match"
            2. Set the file pattern to .*

             

            That seems to stop the system from overwriting the custom build until an actual change occurs in the code repo

            Scott Marshall added a comment - Better workaround:    Set your Change Detection Options to "only changes that match" Set the file pattern to .*   That seems to stop the system from overwriting the custom build until an actual change occurs in the code repo

            Marcin Gardias added a comment - - edited

            Proposed change would break other customers' workflow and the desired functionality already exists in the form of Plan branches.

            Marcin Gardias added a comment - - edited Proposed change would break other customers' workflow and the desired functionality already exists in the form of Plan branches.

            We are continuously seeing this issue. False failed builds are becoming costly as resources are spent investigating.

            Christian Monterroso added a comment - We are continuously seeing this issue. False failed builds are becoming costly as resources are spent investigating.

            Why make Bamboo's UX awkward when it could be slick? I understand where you're coming from, but a developer's life is difficult so the customer's life is easy

            "Customized Build" is more convenient as it is directly available to users from the Run > Run Customized menu item on the plan main page, and it does not require editing the plan or branch configurations. The workaround suggested above is more clicking, and requires more knowledge of Bamboo to understand.  I'm the Bamboo admin for my company, so I understand the suggested workaround (I just don't like it ).  I would have a hard time convincing the rest of our developers that the suggested workaround is the desired way to use the Bamboo build tool. I will also have a hard time justifying how the ghost build that I described in this ticket could be anything other than a design issue or bug that should be resolved.

            Greg Niestrawski added a comment - Why make Bamboo's UX awkward when it could be slick? I understand where you're coming from, but a developer's life is difficult so the customer's life is easy "Customized Build" is more convenient as it is directly available to users from the Run > Run Customized menu item on the plan main page, and it does not require editing the plan or branch configurations. The workaround suggested above is more clicking, and requires more knowledge of Bamboo to understand.  I'm the Bamboo admin for my company, so I understand the suggested workaround (I just don't like it ).  I would have a hard time convincing the rest of our developers that the suggested workaround is the desired way to use the Bamboo build tool. I will also have a hard time justifying how the ghost build that I described in this ticket could be anything other than a design issue or bug that should be resolved.

            Marcin Gardias added a comment - - edited

            gniestrawski538856944 If I understand correctly, you use Plan Branches feature. If that's the case I think there's better approach to handling your use case:

            So you have all repositories configured with variables in place of branch name. What you can do instead of using 'run customised' is:

            • go to build configuration
            • select the plan branch that requires branches on 'secondary repositories'
            • select the variables tab
            • override any plan variables you need

            The advantages of this approach are that you need to do it only once per such branch and that it doesn't confuse Bamboo's change detection sub-system. Actually it starts working exactly as I would want it to if I were in your position, if  you push to feature branch of 'secondary' repository you'll get the correct plan branch build automatically.  On the other hand I am very reluctant to implement 'a fix to a workaround' which can, quite possibly, break other people's workflows.

            Please let us know if the solution described above works for you (or why it doesn't)

            Marcin Gardias added a comment - - edited gniestrawski538856944 If I understand correctly, you use Plan Branches feature. If that's the case I think there's better approach to handling your use case: So you have all repositories configured with variables in place of branch name. What you can do instead of using 'run customised' is: go to build configuration select the plan branch that requires branches on 'secondary repositories' select the variables tab override any plan variables you need The advantages of this approach are that you need to do it only once per such branch and that it doesn't confuse Bamboo's change detection sub-system. Actually it starts working exactly as I would want it to if I were in your position, if  you push to feature branch of 'secondary' repository you'll get the correct plan branch build automatically.  On the other hand I am very reluctant to implement 'a fix to a workaround' which can, quite possibly, break other people's workflows. Please let us know if the solution described above works for you (or why it doesn't)

            This issue isn't an obvious one, so I will explain to provide a little more context:

            Bamboo's "Run Customized" feature is very useful when dealing with multi-repo configurations.  Suppose a build requires 6 different git repos in order to run, and a developer needs to make related changes in several repos.  The changes are pushed to feature branches in each repo for the purpose of code review. The developer has tested the changes on his/her local machine, and wants to execute a Bamboo build that will push a notification to the code review that the build passes.  The branches cannot be merged to master yet because the code reviews are not completed.

            With a single Bamboo job using branch detection, Bamboo may detect one of the feature branches on whatever repository is configured as the default.  If the build is hardcoded to use the master branch of the other repos, then the build of the feature branch fails because the change depends on the other simultaneous changes in the other feature branches in the related repos. This is annoying because as Bamboo pushes a "Build Failed" notification to the code review, and there is no way to clear it other than obtaining a pass from the same build plan. If the build failure occurred on a Bamboo branch that is later automatically cleaned up (eg. due to inactivity) then the failure is stuck on the code review, and the developer has to get Bitbucket admin permissions to bypass the "no failed builds" requirement to merge the code review.

            One way to work around this is to use Plan Variables that define the branch for each repository used in the build, with a default value of "master" (eg. Repo1Branch=master, Repo2Branch=master and so on...).  When a developer needs to make a messy multi-repo feature change, they can "Run Customized" and override any/all of the plan variables to target the desired branch configuration. For example:

            Repo1Branch=myFeatureBranch

            Repo2Branch=myFeatureBranch

            Repo3Branch=myFeatureBranch

            Repo4Branch=master  

            Repo5Branch=master

            Repo6Branch=master

            The build checks out the correct code, passes the build, and pushes appropriate "Build Passed" notifications to each of the code reviews! Excellent

            However, due to this issue, a second ghost build is triggered immediately afterward. Commit detection tells us Author=Unknown committed something git doesn't recognize, and not surprisingly, it fails to build. Here's an example from a recent build I did:

            [unknown] Yesterday 6a3b34ee098c1ce35482d729fa83400371969614

            Bamboo was unable to extract changes between revision 77e455d7c1e5ec63f600a21b1065ab275960baa1 and 6a3b34ee098c1ce35482d729fa83400371969614.

             

            The suggested workaround is removing all Triggers from the build. This means developers must run builds manually, which is inconvenient for the 90% of code reviews that aren't messy multi-repo feature changes.

            Greg Niestrawski added a comment - This issue isn't an obvious one, so I will explain to provide a little more context: Bamboo's "Run Customized" feature is very useful when dealing with multi-repo configurations.  Suppose a build requires 6 different git repos in order to run, and a developer needs to make related changes in several repos.  The changes are pushed to feature branches in each repo for the purpose of code review. The developer has tested the changes on his/her local machine, and wants to execute a Bamboo build that will push a notification to the code review that the build passes.  The branches cannot be merged to master yet because the code reviews are not completed. With a single Bamboo job using branch detection, Bamboo may detect one of the feature branches on whatever repository is configured as the default.  If the build is hardcoded to use the master branch of the other repos, then the build of the feature branch fails because the change depends on the other simultaneous changes in the other feature branches in the related repos. This is annoying because as Bamboo pushes a "Build Failed" notification to the code review, and there is no way to clear it other than obtaining a pass from the same build plan. If the build failure occurred on a Bamboo branch that is later automatically cleaned up (eg. due to inactivity) then the failure is stuck on the code review, and the developer has to get Bitbucket admin permissions to bypass the "no failed builds" requirement to merge the code review. One way to work around this is to use Plan Variables that define the branch for each repository used in the build, with a default value of "master" (eg. Repo1Branch=master, Repo2Branch=master and so on...).  When a developer needs to make a messy multi-repo feature change, they can "Run Customized" and override any/all of the plan variables to target the desired branch configuration. For example: Repo1Branch=myFeatureBranch Repo2Branch=myFeatureBranch Repo3Branch=myFeatureBranch Repo4Branch=master   Repo5Branch=master Repo6Branch=master The build checks out the correct code, passes the build, and pushes appropriate "Build Passed" notifications to each of the code reviews! Excellent However, due to this issue, a second ghost build is triggered immediately afterward. Commit detection tells us Author=Unknown committed something git doesn't recognize, and not surprisingly, it fails to build. Here's an example from a recent build I did: [unknown] Yesterday 6a3b34ee098c1ce35482d729fa83400371969614 Bamboo was unable to extract changes between revision 77e455d7c1e5ec63f600a21b1065ab275960baa1 and 6a3b34ee098c1ce35482d729fa83400371969614.   The suggested workaround is removing all Triggers from the build. This means developers must run builds manually, which is inconvenient for the 90% of code reviews that aren't messy multi-repo feature changes.

              Unassigned Unassigned
              ezeidan Ellie Z (they/them)
              Affected customers:
              3 This affects my team
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: