Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Trigger Bamboo Plan based on Commit message in Bitbucket


[UPDATE Dec 14, 2020] - please see my comment to see how I worked around this.


Hey guys, thanks for the help.


I have 2 plans.

1st plan is triggered by any commits to my development branch. It checks for changes and changes version numbers in a version file and then commits the new version numbers back up to Bitbucket.

2nd plan checks out all the code (including new version number file) and builds and deploys my code bundle.


I have the first plan set to trigger on any commit EXCEPT commits that contain "[ci]" in the commit message, which is what I use to commit the version number changes. This is to prevent infinite looping. This is using Plan Config -> Repositories -> "Change Detection Options" -> "Exclude Changesets" -> with the regex .*\[ci\].*

I want the second plan to trigger only when commits to the same repo CONTAIN "[ci]" in the commit message (ex: "[ci] revving version numbers"). Note, I can't do this all in one Plan because then the re-checkout uses the initially checked commit hashes, not the updated one. And I can't use Plan dependencies to trigger the second build because it also will use the same commit hashes as first plan. I tried using the negative/inverse regex in the "Exclude Changesets" section by writing .*\[ci\].*\n     but this also does not work.


As it is right now, my second plan gets triggered twice, once on the normal commit to the dev branch, and again, when my first plan commits to dev branch. I need it to only trigger that second time.

I have seen people mention inverse regex, but I tried this and it does not work.

I have seen people recommend Script Runner, but I'd prefer to avoid buying extra licenses if possible. Has anyone else had success with this plugin though? If so, maybe I will look into it again if we can't solve this another way.


Please advise. Cheers

3 answers

2 accepted

A bit late but... I found a solution. You need to put a "negative" regular expression in the "Exclude changesets" section in the repository configuration, that include the word that you want.
The regular expression is like :


with this, bamboo will only build commits with this word in the message


Ah that's a fun workaround too. Thanks!

So, I was able to get 'solve' this problem.


  • I stopped using the Bitbucket interface to do my repository checkouts
    • Except for my pipeline-scripts repo, which I checkout manually at the beginning of plan so I can execute all my other stuff, including checkout script
  • I now only checkout my pipeline-scripts repo using the bitbucket checkout.
  • I have a script now that does the rest of the checkouts at the beginning of plan.
  • My first plan still triggers, though, using Bitbucket trigger setup on all my repos I want to track/trigger on. I still use the exclude regex of: .*\[ci\].*
  • At the end of the first 'versioning' plan, I have a script that commits the changed repos
  • I have the second plan set as a Child Plan of the first plan, using the 'Dependencies' tab in the first plan.
  • The second plan has its own checkout script that checks out the needed repos (this will fetch changes from recent CI-related commits.


This setup no longer runs the second plan twice, and I don't have to worry about negative regex because I am using the Child Plan setup. Because I am using custom scripts to checkout code, I am not using Bitbucket's repository caching, which is why everything works now.


Hope this helps guys!

1 vote
Aron Gombas _Midori_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 09, 2021

Better DevOps Automation gives an elegant solution to this.

Create an automation rule:

It's rather straightforward.

Hey Aron, this looks like an awesome option if I was allowed to install extensions! Unfortunately I cannot do that.

Thanks for sharing this though :)

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events