When is it safe to change newly queued builds

I have a tool which programmatically changes the build steps, using the rest api, after a build is added to the queue.

There appears to be a delay of the queuing, if my tool immediately performs changes to the build steps, Teamcity will include such changes in the newly added build. I.e. new builds are added asynchronously to the queue.

That's ok I guess, but is there any robust and deterministic way at all for a tool which uses the rest api, to determine when it's safe to perform changes to build steps of a newly queued build?

I can guess of course, like when then the "waitReason" property of a build gone, or not set to "Build settings have not been finalized" any longer. But is this really the most robust way to determine when it's safe to change build config settings?

0
1 comment

When requesting a build to be added to the queue, several checks and calculations have to be performed, such as dependencies, which means it's much better to do it async. Once the build is in the queue, it should be safe, so the best option is probably to check with the buildQueue endpoint until waitReason is gone. Unfortunately, there is no callback to which you can register for when it's updated, so you will need to poll.

0

Please sign in to leave a comment.