Ensuring specific revisions are used when queuing builds via REST API

Symptoms

When queuing builds using the TeamCity RESTP API, the revisions specified in the API call are ignored, and the build is started on a different branch/revision.

Cause

This often happens when builds are queued using the lastChanges model due to its implementation details. If the change locator provided in the lastChanges model cannot find the specified change, TeamCity falls back to running the build on the latest changes in the Default branch. The problem can happen when a build is triggered shortly after pushing the changes to the remote if TeamCity hasn't discovered the particular change yet.

Resolution

Switching to the revisions model solves the problem. Unlike lastChanges, if revisions doesn't find a specified change, TeamCity will check for new changes in the corresponding VCS Root.

An added benefit of using the revisions model is the ability to directly specify commit hashes instead of providing a change locator. It also allows specifying individual revisions for multiple VCS Roots, which is impossible when using the lastChanges model.

The usage example is available in this article.