I’m using TeamCity for both building and deploying my artifacts to the different environments (DEV, CI, PROD, etc…).
I’m also using the daily Build History Clean-up feature to conserve disk space.
This means I might end up deploying to QA for manual testing, by the time the tests are done (in some cases this could take over a couple of days), the cleanup may have already removed the release candidate build (and its artifacts) from the disk, having to compromise between uploading a release that’s not fully tested to delaying the release on account of unplanned testing.

The solution is build pinning, this is equivalent to Jenkins’ “keep this build forever” button.

But you can’t ask a build configuration to pin you build automatically on success , and in my case, I want to pin the build I’m depending on (I have a build config that builds artifacts and other build configurations to deploy those artifacts to the various environments).

It’s pretty simple to use the TeamCity REST API (on a linux box with curl).

buildmanager is a user I’ve created in order to show that the pinning or tagging were done automatically, otherwise it may have used the user of whoever ran the build

Pin this build:

curl -v --basic --user buildmanager:buildmanager --request PUT "http://localhost/TeamCity/httpAuth/app/rest/builds/id:%teamcity.build.id%/pin/

Pin the BuildArtifacts build, on which I’m depending:

curl -v --basic --user buildmanager:buildmanager --request PUT "http://localhost/TeamCity/httpAuth/app/rest/builds/id:%dep.BuildArtifacts.teamcity.build.id%/pin/

Also tag it (%environment.name% is a configuration parameter I set on my build configurations that deploy to use the environment name in scripts):

curl -v --basic --user buildmanager:buildmanager --request POST --header "Content-Type: application/xml" --data '<?xml version="1.0" encoding="UTF-8" standalone="yes"?><tags><tag>%environment.name%</tag></tags>' "http://localhost/TeamCity/httpAuth/app/rest/builds/id:%dep.BuildArtifacts.teamcity.build.id%/tags/"

I’ve simply used these one-liners as custom scripts in a command line type build step at the end of my deployment build configurations.