How to get user input during a build chain

Is there a way to pause a build chain, waiting for user input?

We need to create a flow which would go something like this:

  1. build & test
  2. [pause the flow] gather "sign-off" from selected users (e.g. they click a "confirm" button in the TeamCity GUI) to confirm that the test results are acceptable
  3. publish ("release") the build artifacts

Is there a way to implement the "sign-off" action? Ideally, the sign-off shouldn't occupy any agent (i.e. we don't want a TC agent to be busy waiting). Would this be possible with a plugin?


Comment actions Permalink


What is generally use for manual advance of a build though the chain/pipeline is a build with no automatic triggers which is run manually.

That is, for the sequence A -> B -> C, (C snapshot-depends on B, B on A). B can have automatic triggers and C can have no triggers configured.
When users want to advance a build to C, they can trigger C selecting proper build of B as the dependency or standing on the build of B invoke "Promote" action either via top-right Actions menu or form the Dependencies build results tab.

If you need input from several users, there is no easy way to do this in TeamCity (rather than setting a separate build configuration per each type of sign-off). You can create an external solution which would query TeamCity for builds via REST API, collect sign-offs and will promote the build to the next stage via REST API. This can also be implemented as a TeamCity plugin.

You can also find useful our general deploymnet setup recommendations.

Comment actions Permalink

Thanks, Yegor, that's helpful.

We do, indeed, have a collective sign-off. As you say, one option is to collect it outside of the TC flow and once the approvals are rounded off, come back to TC and trigger.

Still, can you perhaps think of a way one could implement this as a plugin? (We would consider creating such a plugin; not needing an outside sign-off system would be worth it for us.)


Comment actions Permalink

> Still, can you perhaps think of a way one could implement this as a plugin? (We would consider creating such a plugin; not needing an outside sign-off system would be worth it for us.)

I'd consider adding a project, build configuration or build tab displaying current status for a current build and buttons for accepting sign-offs. Once a button is clicked, it can submit the page to the plugin-provided controller which would update and remember the state for the current build. The state can be just kept in memory or persisted onto disk (e.g. as a file in related build's hidden artifacts).
On receiving last confirmation, the plugin can trigger the next build by "promoting" the chain. The plugin can be activated for a build configuration by adding a special trigger provied by the plugin.

If you have specific questions on the logic, feel free to ask them providing context details.
If you start plugin as a open-source one with permissive license, we can help to solve specific tasks by contributing to the plugin.

Comment actions Permalink


Thanks for clarifying. We now have a much better idea about how to approach this.

One more thing: can a custom tab be added to a queued build already? Or must it be a running/complete build?

If it is possible to collect the sign-offs in a queued build, we would implement it so that there would be no compatible agents for the queued build until all the sign-offs have been collected. This has an advantage over build-chain promotion when there are multiple sign-offs (which in our case there are). Consider this flow:

This is a very cut-down version of our build-chain graph. Both A and B require sign-offs (user confirmation). If we implement it as you suggest, then both A and B would trigger C by promoting the build chain. We would end up triggering C twice.

If, however, both A and B stay queued (with custom tabs) until the sign-offs have been collected, then the events will go like so:

  1. "A" completes sign-off (by a user confirming something in the custom tab of the queued "A").
  2. "A" runs on an agent (possibly a no-op).
  3. "A" triggers "C" (this need not be a build promotion; a simple trigger is just fine).
  4. "C" has a snapshot dependency on both "A" and "B" and it notices "B" already in queue (waiting for sign-off) so it waits. It does not add another "B" to the queue.
  5. When "B" completes the sign-offs, it has a trigger for "C" but thanks to build-chain merging it doesn't add another "C" into the queue.
  6. "C" runs (just once).

Does that make sense?


Comment actions Permalink


Sorry for the delay with replying.

> can a custom tab be added to a queued build already? Or must it be a running/complete build?

Yes. Standard ViewBuildTab allows to display a tab for queued, running and finished builds

Commenting on your scheme:

When using snapshot dependencies, you should either trigger C right away (so that A and B are triggered by C), or "promote" A and B to C (which might be tricky if A and B were not parts of the same chain from the very beginning). If A and B are part of the same chain, it might be the task for your plugin to trigger C only once, not after sign-off of only A or B. However, I'd first explore the former approach of triggering C (and the entire chain under it) as the first step and then just prevent C from starting until all the sign-offs are collected.

You ae right, you can prevent build from starting by using StartingBuildAgentsFilter extension point.

Comment actions Permalink

Thanks, Yegor.

To avoid multiple triggering, we use the first alternative, i.e. (to borrow your words) "trigger C right away (so that A and B are triggered by C)."

However, we also apply one additional trick. We need A, B, and C to share parameters. If these were params defined in C (entered by whoever is triggering C), then A and B couldn't reference them (since params can only flow down along snapshot deps, not up). To deal with this, our arrangement is as follows:

with trigger for JetBrains.xml_126195 (1).png
I'm mentioning this for the benefit of anyone who may have a similar requirement (since the documentation doesn't describe such a set-up). The graph of the overall flow can get quite complex and yet it doesn't cause repeated triggering.

This should also explain why we prefer to implement the sign-off on queued builds. If we achieve that, then T will trigger C, which in turn will trigger A and B, but all will stay queued (i.e. passive, not consuming agent resources) until p


Please sign in to leave a comment.