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

      As part of our release process, we update and tag a particular version of Confluence in CVS. Bamboo may or may not build this exact version, depending on what other commits occur around the same time. After tagging, we check out the tag locally and build and run the tests to make sure our tagged version is okay to release or deploy. As a build server, Bamboo should be able to do this.

      To run a "release build" or "tagged build", the user would select a project, select a VCS branch and tag, and Bamboo would run the normal build process and capture artifacts, etc.

      Bamboo should keep a list of "release builds" or "tagged builds" separate to the normal list of builds, since the normal list of builds has a useful chronological order which release builds would disrupt.

      As a secondary enhancement, the release builds should be configurable separately to the normal builds. That is, they could configured to run different maven targets (including deployment, perhaps), and capture different artifacts (JAR and WAR files, for example).

          Form Name

            [BAM-61] Build nominated versions of projects

            AntonA added a comment -

            This is a duplicate of BAM-1272.

            AntonA added a comment - This is a duplicate of BAM-1272 .

            It would be great if a user can run manual build not only on the latest commit but on any arbitrary change sets and tags.

            Also, any chance this feature can be available for other SCM such as Perforce?

            G2G JPSupport added a comment - It would be great if a user can run manual build not only on the latest commit but on any arbitrary change sets and tags. Also, any chance this feature can be available for other SCM such as Perforce?

            We also employ the method described above for our released builds and this feature is pretty important to us (tagging every build that occurs as described in BAM-620 is not). Would it be possible to have Bamboo scan CVS for new tags, which would automatically trigger a build in addition to commits, and add a label with that tag to the build to indicate that it is a release version?

            I might be going a little too far here, but a logical extension might be to have Bamboo call the Jira API to release a version with the same name as the tag?

            Rob McIntyre added a comment - We also employ the method described above for our released builds and this feature is pretty important to us (tagging every build that occurs as described in BAM-620 is not). Would it be possible to have Bamboo scan CVS for new tags, which would automatically trigger a build in addition to commits, and add a label with that tag to the build to indicate that it is a release version? I might be going a little too far here, but a logical extension might be to have Bamboo call the Jira API to release a version with the same name as the tag?

            MarkC added a comment -

            Ben,

            I've raise your issue re: tagging at BAM-620. We've track that issue from there.

            Cheers,

            Mark C

            MarkC added a comment - Ben, I've raise your issue re: tagging at BAM-620 . We've track that issue from there. Cheers, Mark C

            Matt Ryall added a comment -

            Good point. I guess you'd want to grab the build artifact from the successful build, and deploy that. I don't think there's a way to do that automatically in Bamboo.

            Probably better to raise this as a separate issue for the Bamboo guys. It sounds like a useful idea distinct from my suggestion above. Knowing which Subversion repository version was used shouldn't be a major technical challenge, because this is written to the console when 'svn update' completes.

            Matt Ryall added a comment - Good point. I guess you'd want to grab the build artifact from the successful build, and deploy that. I don't think there's a way to do that automatically in Bamboo. Probably better to raise this as a separate issue for the Bamboo guys. It sounds like a useful idea distinct from my suggestion above. Knowing which Subversion repository version was used shouldn't be a major technical challenge, because this is written to the console when 'svn update' completes.

            Does the dependant build know what revision of subversion we were just built and tested against?

            Our test process takes > 90 minutes, I guarantee someone will check in some random failing code between a successful build and when the dependant build occurs.

            Apart from that, thanks for the suggestion - we'll probably use something like that to initiate the integration environment build and deployment.

            Ben Walding added a comment - Does the dependant build know what revision of subversion we were just built and tested against? Our test process takes > 90 minutes, I guarantee someone will check in some random failing code between a successful build and when the dependant build occurs. Apart from that, thanks for the suggestion - we'll probably use something like that to initiate the integration environment build and deployment.

            Matt Ryall added a comment -

            Most of what you mention can be done with build dependencies, Ben.

            Set your main build to kick off a dependent 'Deployment' plan when it succeeds. Make the deployment plan simply a shell script build that builds your distributable (JAR or whatever), and deploys it into your integration environment. The deployment build can be set to notify by email on every build, so your QA team is notified every time a new build is deployed.

            Matt Ryall added a comment - Most of what you mention can be done with build dependencies, Ben. Set your main build to kick off a dependent 'Deployment' plan when it succeeds. Make the deployment plan simply a shell script build that builds your distributable (JAR or whatever), and deploys it into your integration environment. The deployment build can be set to notify by email on every build, so your QA team is notified every time a new build is deployed.

            As a reverse of this, having Bamboo tag a specific version, or remember what revision the build was (eg. rev 5132) would go a long way to helping us with our integration environment.

            eg.

            Bamboo churns away building every 93 minutes (for us). When a build succeeds, the build is tagged as SUCCESSFUL / INTEGRATION or whatever.

            Then our integration environment notices, picks up that version and deploys into our integration testing environment - where we then go and do performance testing on a distributed set of hardware or UAT etc.

            Ben Walding added a comment - As a reverse of this, having Bamboo tag a specific version, or remember what revision the build was (eg. rev 5132) would go a long way to helping us with our integration environment. eg. Bamboo churns away building every 93 minutes (for us). When a build succeeds, the build is tagged as SUCCESSFUL / INTEGRATION or whatever. Then our integration environment notices, picks up that version and deploys into our integration testing environment - where we then go and do performance testing on a distributed set of hardware or UAT etc.

              Unassigned Unassigned
              matt@atlassian.com Matt Ryall
              Votes:
              7 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved:

                  Estimated:
                  Original Estimate - 32h
                  32h
                  Remaining:
                  Remaining Estimate - 32h
                  32h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified