• 0
    • 1
    • 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.

      We have a maven plugin that is run during our build process, that determines if the currently-building product has already been released with the current version number.

      For example, if we have released product-1.0.0 (ie. a tag exists, possibly produced by build #123), and the current build (#124, or higher) is going to produce another product-1.0.0 artifact, we would like this build to stop.

      Currently, we cannot determine a way to have our build stop at this point, without having the build also fail and report this failure via email to the development team.

      We have configured our build plan to only listen for VCS changes to this particular repository/subproject before starting the build, but we have 3 branches for this project, and when making small configuration changes, occasionally this will trigger a build before we have updated the version number to the next development release.

      We would like a way, either via a task, shell script, maven plugin, etc. to either:

      1) Define a return code that, when examined by Bamboo, will cause the build to stop without failing, or:

      2) Specify for a particular task (shell script, Maven process, etc.) that its failure should not cause a build failure, but rather just stop the build, as the build is unnecessary.

      Here is a detailed example for what we're experiencing:

      For a core dependency, the 'patch' branch is set to 1.2.2, and our 'major' branch is set to 2.0.0. We release a product that depends on the major version of this core dependency, thus "releasing" the 2.0.0 version of the dependency, creating a tag, "dependency-2.0.0".

      We would now like to update our 'patch' branch to be version 2.0.0, since any of our products that are depending on the patch version should be using 2.0.0 also, instead of the 1.2.2 version. But, we also don't want to update our 'patch' branch to 2.0.1 yet, since if we quickly perform a patch release of our main product, we don't want to create an "empty" dependency-2.0.1 tag/release that has no changes. However, updating our patch branch to version 2.0.0 triggers a build, which is stopped by our maven plugin that detects the existence of tag dependency-2.0.0.

            [BAM-14230] Stop build without Failing

            Atlassian Update - 27 April 2025

            Hello,

            Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself.

            Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap.

            Please note the comments on this thread are not being monitored.

            You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here.

            To learn more about our recent investments in Bamboo Data Center, please check our public roadmap.

            Kind regards,
            Bamboo Data Center

            Aakrity Tibrewal added a comment - Atlassian Update - 27 April 2025 Hello, Thank you for submitting this suggestion. We appreciate you taking the time to share your ideas for improving our products, as many features and functions come from valued customers such as yourself. Atlassian is committed to enhancing the security and compliance of our Data Center products, with an emphasis on sustainable scalability and improving the product experience for both administrators and end-users. We periodically review older suggestions to ensure we're focusing on the most relevant feedback. This suggestion is being closed due to a lack of engagement in the last four years , including no new watchers, votes, or comments. This inactivity suggests a low impact. Therefore, this suggestion is not in consideration for our future roadmap. Please note the comments on this thread are not being monitored. You can read more about our approach to highly voted suggestions here and how we prioritize what to implement here. To learn more about our recent investments in Bamboo Data Center, please check our public roadmap . Kind regards, Bamboo Data Center

            This would give us a workaround for the improvement suggested here: https://jira.atlassian.com/browse/BAM-14961

            It's not as clean, but letting a build intentionally stop would give us a way to examine the branch name in the first task and stop progress if it is NOT our release branch.

            Kelly Irvin added a comment - This would give us a workaround for the improvement suggested here: https://jira.atlassian.com/browse/BAM-14961 It's not as clean, but letting a build intentionally stop would give us a way to examine the branch name in the first task and stop progress if it is NOT our release branch.

            Craig Otis added a comment -

            Thanks James, much appreciated.

            Craig Otis added a comment - Thanks James, much appreciated.

            Hi cotis,

            I believe this is a valid use case but I am not sure how many users would need this. Its certainly something that I believe our team should think about before implementing as it could introduce extra complexity into how Tasks behave.

            That said, Ill leave it open for the moment and see if it gets any more interest.

            Thanks
            James

            James Dumay added a comment - Hi cotis , I believe this is a valid use case but I am not sure how many users would need this. Its certainly something that I believe our team should think about before implementing as it could introduce extra complexity into how Tasks behave. That said, Ill leave it open for the moment and see if it gets any more interest. Thanks James

              Unassigned Unassigned
              cdf49162e276 Craig Otis
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: