API

In version 2020.2, we introduced the concept of agentless build steps that can be run outside TeamCity, in third-party services. With this functionality, you can detach an agent from a build even before the build finishes. This helps manage agents more effectively: the earlier an agent gets free from one build, the sooner it can start another build. In the scope of the whole server, it allows running more builds on fewer agents. To learn more about agentless steps, watch this video. What tasks can be offloaded to a third party? Common examples are deploying software with services like Oc

As we promised, we continue the configuration parameters story started in the previous post. Today, I'd like to tell you about .NET related properties. TeamCity .NET plugins provide a bunch of predefined properties indicating that .NET Framework/SDK/Visual Studio/Mono are detected on build agent. Previously you could refer to these properties as to system properties. Now we've changed it. We decided to turn all these properties into configuration parameters, and therefore we've converted all refernces to such properties detected in TeamCity to keep builds running. However, it's not possible t

After our posts about TeamCity's new multiple build steps (previously called "multiple build runners") feature and further changes in .NET build runners, I believe that plugin developers might have some questions to be clarified. So today, I'm going to shed some light on the major agent-side API changes that we've made to support multiple build steps. I hope this post will help you to painlessly improve your build runner plugins. AgentRunningBuild interface no longer represents parameters for a build runner. We've introduced new interface BuildRunnerContext that provides parameters for buil