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

Usage of Maven2 Goals release:prepare and release:perform

    • Icon: Suggestion Suggestion
    • Resolution: Answered
    • None
    • None
    • Maven 2.0.x
      SVN
    • 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.

      Applying following configuration of a Project

      • Pooling on SVN Repository
      • Build Goals : clean package deploy release:prepare --batch-mode release:perform

      In SVN Repository :

      • the build-number.txt is added in svnignore
      • The current Project Version is set to 1.0-SNAPSHOT

      At the first execution, the Build perform all goals correctly :

      • clean and package provide a new SNAPSHOT binary
      • deploy deploys the 1.0.0-SNAPSHOT on Maven Repository
      • release:prepare --batch-mode defines the release informations in release.properties on build Dir.
      • release:perform releases the project by :
        • Updating version from 1.0.0-SNAPSHOT to 1.0.0
        • Releasing the 1.0.0 to TagBase URL
        • Updating version from 1.0.0 t o*1.0.1-SNAPSHOT* in the trunk
        • Extract of release 1.0 in Build.Dir.\target\checkout
        • deploy and site-deploy execution, providing a new released binary

      After execution, a new release is tagged on SVN and the SVN Trunk is ready for the next SNAPSHOT release.
      The Maven repostory is updated with SNAPSHOT and RELEASE repository.

      But sadely, in the next pooling phase, Bamboo reexecutes the Build, because, there are two new changes :

      • [maven-release-plugin] prepare release maven-checkstyle-plugin-config-1.0.0
        • /sfri/trunk/maven-checkstyle-plugin-config/pom.xml (version 7661)
      • [maven-release-plugin] prepare for next development iteration
        • /sfri/trunk/maven-checkstyle-plugin-config/pom.xml (version 7663)

      Then, each Build make some changes, then after each SVN pool, the Build is restarted.

      What is the best way to manage release from Bamboo whitout having more than one plan per SVN URLs ?

      The only short term solution, should be to launch a scm:update goal after the release.

      • Build Goals Tested : clean package deploy release:prepare --batch-mode release:perform scm:update
      • Build Goals not yet tested : clean package deploy release:prepare --batch-mode scm:update release:perform

      What may be the best practice ?

      Rgds

            [BAM-1917] Usage of Maven2 Goals release:prepare and release:perform

            Adrian,

            Thks for these confirmations.

            Since the issue's creation, I experienced more alternative, and finally take the below options :

            Two Bamboo Projects per Application Project :

            1. For Continue Integration (multi-developers meaning) with goals clean package deploy
            2. For Release process with Goals clean package release:prepare --batch-mode release:perform

            I hope that this way to configure Bamboo will be a temporary solution.
            My final needs are described in http://jira.atlassian.com/browse/BAM-1875, and separated in 3 sets of Maven Goals.

            1. clean package
            2. clean deploy
            3. clean package release:clean deployEAR selenium:start-server --batch-mode release:prepare release:perform -Darguments=install

            I do not want to have 3 instances of each Project Build.

            Rds
            Vincent

            Vincent Thoulé added a comment - Adrian, Thks for these confirmations. Since the issue's creation, I experienced more alternative, and finally take the below options : Two Bamboo Projects per Application Project : For Continue Integration (multi-developers meaning) with goals clean package deploy For Release process with Goals clean package release:prepare --batch-mode release:perform I hope that this way to configure Bamboo will be a temporary solution. My final needs are described in http://jira.atlassian.com/browse/BAM-1875 , and separated in 3 sets of Maven Goals. clean package clean deploy clean package release:clean deployEAR selenium:start-server --batch-mode release:prepare release:perform -Darguments=install I do not want to have 3 instances of each Project Build. Rds Vincent

            Hi Vincent,

            Thanks for using Bamboo.

            Bamboo and the Maven "release" plug-in

            Bamboo can be used to run the Maven "release" plug-in, but, you shouldn't enable repository polling for such build plans. As you've found, you will end up in an infinite loop: Bamboo polls your repository, looking for changes, finds changes, starts a build, the Maven release:prepare goal makes changes and commits them to your repository, the build completes, Bamboo polls your repository looking for changes, finds the changes committed by the release:prepare goal, starts a build, and so on, forever...

            If you would like to use Bamboo to perform your releases, you should probably do this using a manually triggered build, that you only run when you are satisfied that your project is ready for release. If you are determined to release on a regular basis, then you may want to use a scheduled build instead.

            If you have a need to integrate your project with other projects on a regular basis, consider using the Maven "deploy" plug-in without the release plug-in, to deploy SNAPSHOT versions of your plug-in to your Maven repository instead. You can set up dependencies between your build plans so that dependent projects build automatically once your SNAPSHOT has been deployed.

            Bamboo and the Maven "scm" plug-in

            There is no need to use the Maven "scm:update" goal, or perform repository updates using any other means, as part of your Bamboo build. Bamboo automatically performs an update from your repository before it starts each build.

            I hope you find this information useful. Please let me know if you need any more help with this particular issue by adding a comment.

            If you have any further questions, it's best to raise them on our support site, support.atlassian.com, where they will receive the most rapid response from our support team. This site, jira.atlassian.com is mainly used for bug reports and feature requests, and may not receive such a timely response.

            Regards,

            Adrian Hempel
            Bamboo Developer

            Adrian Hempel [Atlassian] added a comment - Hi Vincent, Thanks for using Bamboo. Bamboo and the Maven "release" plug-in Bamboo can be used to run the Maven "release" plug-in, but, you shouldn't enable repository polling for such build plans. As you've found, you will end up in an infinite loop: Bamboo polls your repository, looking for changes, finds changes, starts a build, the Maven release:prepare goal makes changes and commits them to your repository, the build completes, Bamboo polls your repository looking for changes, finds the changes committed by the release:prepare goal, starts a build, and so on, forever... If you would like to use Bamboo to perform your releases, you should probably do this using a manually triggered build , that you only run when you are satisfied that your project is ready for release. If you are determined to release on a regular basis, then you may want to use a scheduled build instead. If you have a need to integrate your project with other projects on a regular basis, consider using the Maven "deploy" plug-in without the release plug-in, to deploy SNAPSHOT versions of your plug-in to your Maven repository instead. You can set up dependencies between your build plans so that dependent projects build automatically once your SNAPSHOT has been deployed. Bamboo and the Maven "scm" plug-in There is no need to use the Maven "scm:update" goal, or perform repository updates using any other means, as part of your Bamboo build. Bamboo automatically performs an update from your repository before it starts each build. I hope you find this information useful. Please let me know if you need any more help with this particular issue by adding a comment. If you have any further questions, it's best to raise them on our support site, support.atlassian.com , where they will receive the most rapid response from our support team. This site, jira.atlassian.com is mainly used for bug reports and feature requests, and may not receive such a timely response. Regards, Adrian Hempel Bamboo Developer

            Finaly, the usage of scm:update as no effect.
            It appears that each build stored its own Last Revision used at the start of the build.
            Even if the Workspace is updated from Maven, the Build is executed because the lastRevision number is not updated at the end of the Build.

            Is there a simple to update teh Last Releaase Number through a Post Action ?

            Vincent Thoulé added a comment - Finaly, the usage of scm:update as no effect. It appears that each build stored its own Last Revision used at the start of the build. Even if the Workspace is updated from Maven, the Build is executed because the lastRevision number is not updated at the end of the Build. Is there a simple to update teh Last Releaase Number through a Post Action ?

              Unassigned Unassigned
              5d77aaa81033 Vincent Thoulé
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: