When releasing a Maven project with the mvn release:prepare command, the related commits are ignored by Bamboo.
      This is OK for the first commit (starting with "[maven-release-plugin] prepare release"), but the second commit should not be ignored ("[maven-release-plugin] prepare for next development iteration").

      The exclusion pattern is hard-coded as:

      \\[maven-release-plugin\\].*
      

      The following pattern would be more appropriate:

      \\[maven-release-plugin\\] prepare release.*
      

            [BAM-12465] Allow default commit filtering to be editable

            Scratch that - my use case is not the same, and I just found the Exclude changesets option in repository setup.

            Gary Kennedy added a comment - Scratch that - my use case is not the same, and I just found the Exclude changesets option in repository setup.

            +1 - I'd like to be able to ignore certain commits from the jgitflow-maven-plugin

            Gary Kennedy added a comment - +1 - I'd like to be able to ignore certain commits from the jgitflow-maven-plugin

            Is there any update on this? We've upgrade to bamboo 5.7.2 and the issue still exists. We are not getting any builds after a maven release to deploy the next snapshot versions.

            Patrick Phelan added a comment - Is there any update on this? We've upgrade to bamboo 5.7.2 and the issue still exists. We are not getting any builds after a maven release to deploy the next snapshot versions.

            While I certainly agree a configurable option is needed, I would argue that the default commit filtering is actually correct logic for most cases, at least in our experience. We actually had some issues before this was added. If you don't filter out the second commit, "preparing for next development," you end up with an endless cycle of builds when doing fully automated releases. For our teams doing "continuous delivery" style development, every commit results in a release being cut using the Maven release plugin, which subsequently results in an automatic deployment to a test environment.

            David Ehringer added a comment - While I certainly agree a configurable option is needed, I would argue that the default commit filtering is actually correct logic for most cases, at least in our experience. We actually had some issues before this was added. If you don't filter out the second commit, "preparing for next development," you end up with an endless cycle of builds when doing fully automated releases. For our teams doing "continuous delivery" style development, every commit results in a release being cut using the Maven release plugin, which subsequently results in an automatic deployment to a test environment.

            Ben added a comment -

            Agreed, is there no way of fixing the logic, or at least make it configurable?

            Ben added a comment - Agreed, is there no way of fixing the logic, or at least make it configurable?

            But James, it doesn't work and the logic is incorrect. The maven release plugin may not make a no-op change at times. On a release the poms are changed an you definitely want a build being kicked off to deploy the newer snapshots. This is more than an inconvenient issue. Is there any update on fixing it?

            Patrick Phelan added a comment - But James, it doesn't work and the logic is incorrect. The maven release plugin may not make a no-op change at times. On a release the poms are changed an you definitely want a build being kicked off to deploy the newer snapshots. This is more than an inconvenient issue. Is there any update on fixing it?

            Hi Ben,

            I agree that this may inconvenient at times. The logic here was to prevent Bamboo from building unnecessarily, such as when maven commits a tag and other situations where the release plugin makes a no-op change.

            Thanks
            James

            James Dumay added a comment - Hi Ben, I agree that this may inconvenient at times. The logic here was to prevent Bamboo from building unnecessarily, such as when maven commits a tag and other situations where the release plugin makes a no-op change. Thanks James

            Ben added a comment -

            Hi James,

            I agree with Patrick; the primary purpose of the maven release plugin is to release and so the very next thing that should happen is a rebuild of the snapshot - so I'm not sure why you'd disable this by design.

            I would like to see a much tighter integration with Bamboo and maven release plugin.

            Thanks,
            Ben

            Ben added a comment - Hi James, I agree with Patrick; the primary purpose of the maven release plugin is to release and so the very next thing that should happen is a rebuild of the snapshot - so I'm not sure why you'd disable this by design. I would like to see a much tighter integration with Bamboo and maven release plugin. Thanks, Ben

            This is a most inconvenient issue for us. We have multiple internal dependencies between maven projects which are built in bamboo and following a release we do not get build of the next snapshot versions automatically since bamboo filters out the maven release plugin commits.

            I can't understand the reason for this in the first place! Surely every svn commit should be built by bamboo? Why would you ignore maven release ones so you wouldn't get the latest snapshot built?

            The workaround we've had to put in for our bamboo installation is to recompile that class file that defines the filter (FilterChangesetAwareRepository.java) and drop it into the bamboo-api jar. Quite inconvenient as I'm sure you'll agree, and an upgrade lately of bamboo resulted in us having to do the same hack again.

            Patrick Phelan added a comment - This is a most inconvenient issue for us. We have multiple internal dependencies between maven projects which are built in bamboo and following a release we do not get build of the next snapshot versions automatically since bamboo filters out the maven release plugin commits. I can't understand the reason for this in the first place! Surely every svn commit should be built by bamboo? Why would you ignore maven release ones so you wouldn't get the latest snapshot built? The workaround we've had to put in for our bamboo installation is to recompile that class file that defines the filter (FilterChangesetAwareRepository.java) and drop it into the bamboo-api jar. Quite inconvenient as I'm sure you'll agree, and an upgrade lately of bamboo resulted in us having to do the same hack again.

            Hi Alexander,

            As a workaround, you can specify -DscmCommentPrefix="some text" as part of your Maven goals so Bamboo will not filter these commits.

            Thanks
            James

            James Dumay added a comment - Hi Alexander, As a workaround, you can specify -DscmCommentPrefix="some text" as part of your Maven goals so Bamboo will not filter these commits. Thanks James

              Unassigned Unassigned
              smaiyaki Sultan Maiyaki (Inactive)
              Affected customers:
              11 This affects my team
              Watchers:
              14 Start watching this issue

                Created:
                Updated: