![]() Even if the build is only available to run on the 5 agents in the pool, it could consume all detached build licenses available on the server. The count of detached builds is global, so regardless of how many agents are in a pool available to run a particular build, the detached agent count can consume all detached agent licenses on a server. The limit is the same as the number of agent licenses on the server. Detached Build Licensing (TeamCity)Įven though detached builds do not consume an agent, the TeamCity server has a limit to the number of detached build agents that can be running at one time. ![]() The parameter here is the global team city build id () that uniquely identifies an instance of a running build. This call tells TeamCity to mark the build as completed. The calls look something like below and full documentation can be found in TeamCity BuildApi REST documentation. The external service that was called before the build was detached needs to call back to TeamCity through the REST API. To show status messages, log errors, or finish the build requires an API call back to TeamCity. So the UI shows the build as still running even though there is no longer an agent actively executing it. However, from the UI and the TeamCity Server perspective the build continues to be in progress. This can be done inside PowerShell or a command line build step by echoing the service message to the console: echo #teamcityĪs soon as the build receives the buildDetachedFromAgent service message it releases the build agent back to the agent pool so that it can service a new request. When the build is detached the TeamCity console shows the build as continuing to execute.Ī build step can detach the agent by emitting the service message #teamcity. This is accomplished by using a callback approach. It makes it possible to simulate the behavior of a synchronous operation on a TeamCity agent even when the call to the external service is asynchronous. This was designed for calling external asynchronous services from a TeamCity agent. Starting with the 2020.2 build of TeamCity, there is a feature called detached builds. ![]() This makes it difficult to trigger other builds or use the deployment build as a snapshot dependency because it’s not clear when the deployment is actually complete. This is good because it doesn’t consume an agent while waiting, but bad because there is no indication in TeamCity that the deployment is still executing, no indication of the current status, and no reporting of the final result of the deployment. It does not block until the deployment is complete. Unlike most build tasks executed in TeamCity, the AWS call returns as soon as the message is received. An example of when you might want to do this is to make CloudFormation updates or initiate a deployment using CodeDeploy. One of the challenges with invoking a process in AWS from TeamCity is that the call to AWS is usually asynchronous. The most common solution I could find online was running sfc /scannow on the Windows machine but it did not help.TLDR Use TeamCity detached builds and callbacks to provide a more seamless integration between TeamCity and AWS Services. I've tried looking into this exception code more but with no success. The exception code hex ( 0x0000409) matches the exit code seen in TeamCity build log. This turned out to not be the case, as I could see the java that came bundled with the TeamCity agent installer is in fact 64 bit.ĭigging deeper into Windows logs, I could see the error with the exception code logged. In directory: C:\opt\BuildAgent\work\xxxxxxxxxxxxxxĪfter some research, I found that this may be caused by the TeamCity agent using a 32 bit version of java and attempting to run WSL which is 64 bit. Starting: C:\opt\BuildAgent\temp\agentTmp\custom_scriptxxxxxxxxxxxxxxxxx.cmd Attempting to run a bash script using WSL produces no output and the following error in build log can be seen:. ![]()
0 Comments
Leave a Reply. |