TC use case with Perforce and {RPM,DEB} builders


Good evening,

I'm trying to build a Proof of Concept for a CI-CD pipeline at work where we'd take out Jenkins and others to replace it with TC; I'd like to see if what I'm thinking is possible, and if so, how to go about implement it.


Currently we have a Perforce trigger that sends notifications to Jenkins whenever we have a new submit on a specific project. Once Jenkins is notified it triggers a RPM or DEB build of the project, and ships it to our artifact repo.


I'd like to replace it this way, if it's possible, and if so, could you please direct me to the proper documentation ?


First off, my current TC setup:

One TC (2019.2) server

1 RPM builder VM running on CentOS 8, with a TC build agent on it

1 DEB builder VM running on Debian 10.0, with a TC build agent on it

In the future, I'd also have a DockerBuilder VM with a TC build agent on it, but I'm not there yet.


What I'd like is the TC server be aware of a new Perforce changelist being created, and pull the data, send it to both builder VMs, and let each VM create its specific type of package.


Is this possible under TeamCity, and if so, where can I find proper documentation on this. The VMs could be replaced with docker containers, but it's not a must. I already have the VMs up and running.






Comment actions Permalink

I forgot to mention : those RPMs and DEBs are mainly python3 code, so no need to build binaries (eg: using Makefiles, c++, etc). I only need to package the python code in distro-specific packages.



Comment actions Permalink

Hi Jeff,


Your requirements seem to be quite straightforward. You would like to set up (at least) two different build configurations (in the same project or separate, this will depend on the degree of configuration that needs to be separate), then add a VCS Root to the common parent project that points at the perforce repository, add all the parameters for it to be able to track properly your changes, then add a VCS Trigger to trigger a build when changes are detected.


Each build configuration will have build steps that are executed in order in sequence to build the packages. TeamCity will automatically (unless configured otherwise) download the sources from the vcs roots attached to the build configuration, and will run your steps on that same directory, so you don't need to take care of that part, but the building process will need to be configured on your own end. TeamCity does not provide a bundled python plugin, so your options are either looking for an external one, or running it via command line scripts. In case you can run some of those steps in parallel, you would want to set up each of those steps in separate build configurations, then join them hierarchically via snapshot dependencies, which determine the order in which they are built. Keep in mind that in order to run build steps in parallel, you will need free compatible agents.


In order for a build agent to be compatible with a build, or rather, to restrict which builds run in which agents, you can either set agent requirements at the build configuration level, or you can set the build agents to different pools, and then assign the pools to projects, or configure for each agent which builds it's allowed to run.


By default, VCS Roots check for changes on a given period of time, by default 60 seconds. You can adjust this to your liking, but please keep in mind that this are requests to servers, so setting a rate too high might lead to too many requests. TeamCity also supports post-commit hooks from the repository server.


This would be the related documentation articles:

-VCS Roots (repository):

-Build configurations:

-Build chains (A full build process with the possibility for parallel configurations):

-VCS Triggers:

-Post commit hooks:


This should cover pretty much everything, as far as I can tell. Check out the related topics on each of the documentation sections to get more information about those. If you have any further question, don't hesitate to ask.

Comment actions Permalink

Denis Lapuente, thanks for the extensive reply, and more importantly, the related links at the bottom of it.


Nice thing about End of Year holydays is that I've plenty of time to play with it and see how it goes !


thanks again for everything !




Please sign in to leave a comment.