Dynamic build steps based on commit hooks from Perforce?

I want to do something that shouldn't be too fancy but Googling isn't helping me. Hopefully this forum can.

Currently we build a product that has 4 separate debug-like configurations as 4 build steps within 1 product's task. Every build step is a custom command line which runs our own build script. I want to get us to a point where we're building all 4 build steps nightly but when the product gets tested by rapid Dev/QA improvements, I'd rather we only run 2 of the build steps to both ease the load on our build agents and quicken the continuous integration process. I also want to add the ability to allow developers to put a commit hook in their commit messages that would add build steps as necessary. For simplicity's sake, think of it this way:

  1. When a developer commits with no hooks, 2 build steps run.
  2. When a developer commits with --all in their commit message, 4 build steps run.
  3. 4 build steps run one per night automatically.

Originally I figured I could pass in a custom parameter to the TeamCity task and use that parameter as a simple if/else command in the build step. However, I cannot seem to find any way to retrieve the commit message passed through perforce. Does TeamCity have access to this? If so, what is the parameter name for it? If not, do you folks have any other suggestions for how I can accomplish my goal? If it helps, keep in mind that all the build steps CAN be consolidated into just 1 step and written as a long script, we just keep it modular for now so we can easily add and disable extra test steps as needed.

I would also like to add that we have a commit hook service running if need be, so we can take triggering out of the hands of TeamCity and put it in the hands of the service. This, in turn, would allow calling TeamCity's API with custom parameters when commit hooks get tripped. However, I think doing things through this process is overkill for this feature and taking the triggering out of the hands of TeamCity's "check for VCS updates" default functionality would be a bad and messy prospect.

Thank you for any and all help!

Comment actions Permalink

Hi Dave,

It is not a good practice to change the logic of build inside build script. In this case it will be difficult to interpret the results of the build and also the statistics of the builds (for example average build time) will be uninformative.

In your case I would recommend to configure two different build configurations. The first one A consists of two build steps and the second one B of four build steps. And configure the following VCS triggers with trigger rules for these build configurations:
A - VCS trigger with trigger rule -:comment=all
B - VCS trigger with trigger rule +:comment=all and Schedule Trigger to run nightly build.

Comment actions Permalink

The reason we want to have dynamic tasks is to keep our total task numbers down. Duplicating tasks will, unfortunately, confuse developers and create a lot of tasks doing a lot of polling. The way I see it, we've recently been allowed dynamic VCS parameters and we make full use of it, so I see no reason why that flexibility cannot be extended in the way I'm suggesting.

We don't use build statistics. They have not been necessary for our TeamCity purposes which are purely driven by the automation of builds.

With that in mind, despite it being "bad practice" is there still a way to do that which I'm asking for?

Message was edited by: Dave Kap to be nicer. ;)


Please sign in to leave a comment.