Trigger TeamCity job when specific branch is merged to Master

Any DevOps who has been involved in some serious CI/CD pipeline architectures have met these particular requirements at least once in his life:

  1. Detect hotfix* branches that are merged to Master
  2. Detect feature* branches that are merged to Master
  3. Automatically trigger a job if (1) is true
Although most build systems support this feature (I know for a fact that this is the case for Bamboo and Jenkins) and the methodologies are similar, this blogpost will focus on Teamcity, probably because I saw a lack of documentation on the matter.

Teamcity is notorious for being tricky! The only way to trigger merges is by listening to the commit messages. With this in mind, we will bake our commit messages to reflect our needs.

Assumptions:

We will assume that the commit message looks something like:
git commit -m "hotfix-*"

Trigger when HotFix branch merged to Master:







Trigger when Feature branch merged to Master:







In both cases, the VCS should be only monitoring the Master branch:



Calling setState() behind an async call in ReactJS

I have blogged about how dangerous it is to use setState() during component lifecycle methods or render() functions. This is because the component can end up in an endless nested deep render. Dan Abromovic and the creators of ReactJS have also talked a lot about this subject. This is why we associate setState() with an event, like a button click.

A similar design pattern exists in ReactJS when we try to use setState() after calling an async function. In Redux we would not have this problem of course. However let's say you are rendering a location pin inside Google Map without the complexities of Redux state management. So all we want is:


  1. Geocode an address by calling Google Maps API
  2. Wait for the API response
  3. Set the map marker state so you get the pin at the right location

If step (3), the setState() function, is called before we get the API response, ReactJS is most definitely going to throw an error? Why? Because calling setState() before the component has fully mounted, or is still rendering, or is re-rendering, is a cardinal sin in ReactJS. 

So to make sure that step (3) is always called at the very end, we can easily make use of the async functions. Note that in setState(), the common pattern to call it synchronously, is to bind it to a function. Checkout this working code below to understand what I am saying: