Adding an interruptable delay in build chain
Hello,
I've inherited a TeamCity setup from a colleague that has left the company. They have a build chain that does the following:
- Send an email that a build will start in 5 minutes
- Pause for 5 minutes
- Build and deploy the software
The idea is that during the 5 minute window team members on the target servers can object to the new deployment and it can be stopped.
The problem is, the "pause for 5 minute" logic is a busy wait. It's a loop that sits for 5 minutes to pass before proceeding to the next step. That means one of our build agents is sitting, doing nothing for 5 minutes.
This is starting to become a problem now and I don't know how to fix this. Does anyone else have a setup like this? And if so, how did they structure it so that a build agent isn't locked up for a long time doing nothing?
Thank you,
John
Please sign in to leave a comment.
Hi John,
adding pauses to the builds is not currently implemented, and the only way to do it as of now through teamcity it is via a build step that sleeps away the required time.
Another option would be to create a custom plugin for your scenario. You could, for example, create a custom plugin that adds some button that upon being clicked sets up an async task that sleeps for those 5 minutes, then triggers the build via either internal objects or the REST API. This doesn't exist for now, though, so you might need to create it.
Of course, for that same scenario you could create any app, not necessarily within teamcity that performs that exact task as well.
How about in the scenario where you'd like to pause the build for human interaction? For instance, I would like to pause on the step in my build chain before it pushes to our PROD environment just to do a sanity check. Is that possible in 2017.2.1+?
Hi Lou,
this isn't currently directly possible, it's a common requested situation included in this scenario here: https://youtrack.jetbrains.com/issue/TW-17939
This said, there seems to be a rather simple solution to that: Split the build configuration in two, the first part does the build, the second build configuration does not have any trigger, can only be run manually and by the people who should check it, picks up the artifacts and pushes them to PROD. You can set up notifications if required, grant permissions only to the right people, etc, which cannot be done within a single build configuration.