Cleaning an agent depending on which Trigger is used?

I have a couple of questions, I am just setting up a new TeamCity server to replace some old python scripts that we used before to do Continuous Integration.

Firstly, I would like to Clean out an Agent based on which Trigger has started a build. for example, we have a lot of 'rolling' builds in the day as changes come in via Accurev. We don't do a 'clean' for each of these as the full test run can take hours.  But, we have a nightly build that we do want to clean out first. I can easily set up both build Triggers, but what I would ideally like to do is have a property be set to indicate which Trigger was used, so we can have our build system know if it should be doing a clean build or a rolling build.

A separate issue is that I have an HTTP link that is output in the log from our build very early, which I would like to somehow report in the TeamCity UI -- it is a link to the detailed logs/progress of our build system. Is there a simple way to do this or do I have to write a plugin to extract this from TeamCity?

Possibly I would be better off combining both needs into a custom Test Runner that could do this?#

Any feedback would be great. I don't mind creating a custom Test Runner if that is the best way to go.


Comment actions Permalink

A quick update: thanks to the helpful Support guys I've now voted on this Issue which I think is what I want
I may need this urgently enough to implement it myself as a custom plugin...

Also I am going to look at using messages on the log output to TeamCity to publish a link to my other server

At some point I may still want a custom Test Runner though, because at the moment all the command line args are rather hard to read in the tiny edit box, so it would be good to split them up into separate properties.

Comment actions Permalink

Another update to the HTML link - I made my build output a tiny HTML file that just had a 'meta' refresh tag to forward it on to my other server, then used the publishArtifacts message and custom report tabs and this is now perfectly integrated into my TeamCity. I like how it even puts the other server in a sub-frame. Great stuff and no plugins required :)

I think I'll still need a custom plugin for my 'nightly clean' build though. I may just make a Template for now and set up two Configurations as a test, but really I just want the one Configuration that is triggered in very slightly different ways.

Comment actions Permalink

Hi again,

I have made some progress and now have a custom trigger from my own Plugin which I can use to start builds on a given schedule - its not as fully featured as the Scheduled Trigger yet but it should be sufficient for what I need.

I'm trying to pass Parameters from my Trigger to my Build. I had thought the TriggeredByBuilder would allow me to do this as it seems to have some addParameters() methods - also, I have seen that VCS Plugins can clearly pass parameters such as which p4 transaction to test. However it doesn't seem to be working.

e.g. my code is:

    private void triggerAnEpochBuild(PolledTriggerContext context)
        BuildTriggerDescriptor descriptor = context.getTriggerDescriptor();

        // construct parameters for build
        TriggeredByBuilder triggeredByBuilder = new TriggeredByBuilder();

        // TODO: have user defined parameters
        triggeredByBuilder.addParameter("env.EPOCH", "1");
        triggeredByBuilder.addParameter("env.CLEAN_BUILD", "1");

        SBuildType buildConfiguration = context.getBuildType();

        log(String.format("Epoch - adding build %s to queue with params %s", buildConfiguration.toString(),

        // kick off the build with our parameters

But I get a build that just has the same parameters as a normal build, but with the TriggeredBy set to##env.EPOCH='1'env.CLEAN_BUILD='1'

Which is not really what I was expecting!

Is this the correct way to pass parameters on? I notice the thread on javascript:; takes a different approach (which I can't find much documentation on).

Comment actions Permalink

I can confirm now (thanks to some help in the other thread) that following the method in the javascript:; thread does work!


Please sign in to leave a comment.