Automatically pin the current build


I have a configuration where the last step in the configuration runs a script that executes REST API commands to pin the current build.  In the script, I use %teamcity.serverUrl% and to get a list of all the builds in the configuration.  Then I unpin all those builds.  Then I utilize to pin the current build.  I get an error because it seems the build doesn't exist (in the DB?) yet and therefore can't be pinned.  Is there a proper way to do this or am I just doing something wrong?  Thanks!

Comment actions Permalink

Since there doesn't seem to be a built in way to do this, we've come up with a work around.

The goal is to automatically pin the current build every time the configuration is run.  The issue is the build doesn't exist in the DB until the configuration has completed running.  So when we try to do a REST API call to pin the current build as it is running, the DB returns saying the build ID doesn't exist.

This is how we got around it.  First, we created a Python v3 script (let's call it that uses the "requests" Python module to send an HTTP get request to TeamCity to add a build to the queue.  As part of the HTTP URL, we pass 2 system variables, the ID and build type of the build we want to pin.

Here is the TeamCity documentation for building up the HTTP get URL.

Next, we create another Python v3 script (let's call it that again uses the "requests" Python module to send TeamCity REST API requests to the TeamCity server.  In this case, there are three unique requests:  1. get a list of all builds for a configuration, 2. Unpin all those builds, 3. pin the latest build in the configuration.

Here is the TeamCity documentation for the REST API.

Now, to connect everything together.  Here are all the parts:

  • Python script 1:
  • Python script 2:
  • Configuration 1 (this is the one we want to automatically pin with every build)
  • Configuration 2 (this runs the script

  1. As the final build step in Configuration 1, execute
  2. adds Configuration 2 to the TeamCity build queue (this passes Configuration 1's build ID and build type to Configuration 2)
  3. Configuration 1 finishes
  4. Configuration 2 runs, executing ( is passed those 2 system variables; remember the ones in the HTTP get request above)
  5. Since Configuration 1 is finished, it exists in the DB now and is pinned
  6. Configuration 2 finishes

We added a delay (5 second sleep call) in so we didn't run into race conditions between Configuration 1 and Configuration 2.

Hope this helps someone else out!

Comment actions Permalink


I just opened this feature request: please vote for it if you find it useful:


Please sign in to leave a comment.