Making long call to external machine agentless

Answered

I have a simple build that consists of a call to an external machine that can take hours to complete. There is no build step with actual build, this is just an external process.

I wish to make the build step agentless. I have watched a video about agentless build steps, but I can't figure out how to make the build step agentless. I do not have full understanding of build chains and deployment builds.

Can anyone explain step-by-step how I can make this build agentless?

4 comments
Comment actions Permalink

Hello!

TeamCity has a feature called service messages. You can write into stdout a message in predefined format, and TeamCity will handle it to some effect; those messages may be used to report tests, update build parameters, change build status and many else. Detaching a build is handled through the service message too. 

Suppose you have a build A with step A1 where you make the long call. Depending on the call type, you may either modify A1 or add new A2 step to ensure that after the call is started, you print out the following line:

##teamcity[buildDetachedFromAgent]

For example, A2 can be a simple Command Line step which consists of

echo ##teamcity[buildDetachedFromAgent]

If you have A1 defined as a script, it should be easy to modify that one to the desired effect, too. 

When TeamCity Server receives this line, it will detach the build from agent and free it up for the next build. Build will be considered running until you finish it by sending a REST API call as defined here. If needed, you can report the intermediate status of the call (if available) through the REST, too. The trick here is that you would have to send the REST API requests either from the external machine (when the call is finished), or from another external entity which is aware of the call status. 

I hope this helps; please let me know in case of any other questions. 

0
Comment actions Permalink

I am afraid I do not understand why the build should be detached in build step 2 (A2), since it wont happen until A1 is completed. Isn't the build supposed to detach before the long call?

0
Comment actions Permalink

Hello!

The idea is that the call is ongoing while you run the step 2 (or, in case you do the call and send detach service message in the same script, call is running asynchronously - for example, if you run a REST method and do not check for the response, detaching the build instead). 

This puts certain limitations on the feature usability; you can only detach the build if the ongoing activity does not use build agent, for example, if it is not running as a sub-process started during the build (as this would mean the agent is busy and cannot process the next build). 

If you detach before making said call, agent will not be able to handle the following activity (in fact, there is some delay between agent publishing the message and it going to the server, due to the build messages being sent in batches, so it would likely start the call, but would stop any sub-processes as soon as server instructs it to treat the build as detached). Due to that, you need to ensure agent is doing nothing when you detach. 

Should there be any other questions or concerns, please do not hesitate to reach out. 

0
Comment actions Permalink

Thanks, I figured this out. I start the process in step 1 asynchronously. 

0

Please sign in to leave a comment.