Multiple TeamCity builds triggering on Azure DevOps Pull Request


Hey all, I'm running into an issue and wondering if anyone has a solution for it.

What I would like:

One Build Configuration which triggers a build when a Pull Request is created. That Publishes a Commit Status back to Azure DevOps GIT repo.

When the pull request is completed I would like 1 build per commit created from the master branch.

What I've ended up with so far:

I have a build configuration that is triggering a build for each commit on master, but as a side affect, when a Pull Request is created it is creating multiple builds. It appears to be one build per commit done in the feature branch. 

I believe the issue is with the build Trigger, as I do have " Trigger a build on each check-in" toggled on, which is exactly what I want for the master branch, but I want Pull Request branches to only trigger one build.

Extra details I think may be useful.
Using Azure DevOps GIT repos.
Out branch spcification for VCS root is:
     +:refs/(pull/*/merge)   --I'm wondering if this actually needs to be "refs/pull/*/head" as I type this out


Anyone have any thoughts?

While researching this issue I did run across the build feature "Pull Request" which I had overlooked originally when setting this up. But it looks like that doesn't support Azure DevOps yet.

Comment actions Permalink

Hi Josh,

Unfortunately, at the moment, it is not possible to build some branches with per-check-in builds, and other branches (or pull requests for that matter) without them within one build configuration. This related feature request would cover your case though: Feel free to vote for it.

As a workaround, you can set up different build configurations to build master and pull requests. That would allow you to specify different VCS Trigger settings for each build configuration.

Regarding Pull Requests build feature support for Azure DevOps, it is coming out shortly:


Comment actions Permalink

Additionally, when creating another build configuration, you can use Templates to make it easier to introduce changes.

If you would like to avoid having different build configurations for builds master and pull request builds, you can work around not being able to add more than one VCS Trigger in a build configuration.

To do so, set up the VCS Trigger to monitor master, and Schedule Trigger for the pull requests branch. Set the Schedule Trigger to fire off every X minutes with a cron expression. That would give you two similar triggers with the difference of having the per-check-in builds in one of them.


Comment actions Permalink

Thanks for the response Anatoly! We will most likely go with the additional scheduled trigger as we really like being able to view all of the builds under one configuration. If that doesn't work out well then we'll split it between two configurations.

Comment actions Permalink

As mentioned above I have the branch specification set to:


With the latter change suggestion, I assume I would remove that entry from there and add that to the scheduled trigger "Trigger rules" section. Thus, causing Pull Requests to build off of that trigger as well as any tags that are prefixed with "build". Is that right?

Comment actions Permalink

Correct. The two triggers should have different trigger rules.

Comment actions Permalink

I removed the branch specification from the VCS root and set up the trigger rules as mentioned above. That was not triggering a build on Pull Request. (Since a build is a requirement for the Pull Request I don't know if it was triggering a build in master after commit.) So I made some changes.

  • I put the branch specification back in to the VCS root
  • updated the VCS Trigger to include "+:<default>" in the branch filter.
  • updated the Schedule Trigger to include:
    in the branch filter.

Now, when a Pull Request is triggered I see "X non-built Branch" where X is the number of new pull requests. I can manually run the build and that does submit the status back to Azure DevOps. I think I'm missing something in trigger. Does anyone see something in our config that would cause this behavior?

The previous posted screen has not changed, but the "Additional Options" on that same screen I updated the branch filters:


Please sign in to leave a comment.