You’d typically attach a VCS trigger to your build to cause it to queue automatically when changes are detected via a VCS root, however, the trigger itself might not always fire as expected. Here’s why:
Triggers are actually more like events and therefore won’t fire for changes that were committed prior to the point the trigger was created or enabled.
Whilst this might seem obvious to most, it becomes less so when you’re disabling and re-enabling a trigger. Consider the following example:
- Bob pauses triggers on their build configuration to make some changes to the config; meanwhile:
- Fred pushes a commit to the remote, sits back and waits for his build to run
- Bob finishes his work and enables triggers on the build configuration once again
- Fred checks TeamCity and finds no build despite his change being listed as a “Pending Change” on the build config
- Jim pushes a new commit and suddenly a build queues up with both Fred and Jim’s changes
As you can see, it’s relatively easy for teams to get into a situation where their builds don’t trigger, but they can’t immediately see why.
In these situations the only options really are to queue up a build manually, or wait for a future change to fire the trigger. Given this, I’ve started checking pending changes after activating a build’s triggers again to see if I need to manually kick off a build to avoid confusion.