![]() Build agents are chosen based on CPU rank heuristic. This is pretty standard support provided by teamcity. Whenever we see a change in vcs root, we trigger a build ( add it to the build queue ) and one of the build agents will pick up them. For the notational purposes, let's call them A, B, C, D, E. Our teamcity setup has five build agents. Okay, I will keep the problem statement pretty clear here. Again, if you send the REST request yourself to a build that has no automated triggers, teamcity will not try in itself to override your settings. A separate build that has the automated trigger (typically VCS, but can be scheduled, or any other of course), then it runs the calculations you want to run, and once you have everything compiled, just send the trigger to the actual build via REST. If you still want teamcity to automate triggering so you don't have to but, in the process, run some script to customize some of the parameters, such as the agent, the easiest approach is to have a "triggering build". Dependencies, automatic triggers, external scripts or other modifications to the build configurations might be disrupting here and we would need to have that information to know why your setup doesn't behave as expected. If this is not the behavior you are observing, then it is very likely that there is some configuration in your setup that you haven't disclosed and is interacting with the process. ![]() That way, teamcity will not attempt to trigger or to assign another agent, it will only process your request and assign the agent you specified. ![]() If you don't mind triggering yourself via REST, as you mentioned, then simply remove all automatic triggers from the build configuration and trigger via REST specifying the agent. I think you are making this seem a lot more complex than it actually is. Sorry, Anatoly has been a bit busy this last week, I'll take over to avoid further delays. In short, We want to take control of TeamCity agent - build assignment. Hope this explains and please suggest the best way. I can modify it and trigger builds accordingly but this seems to be a bit more work than the 1st option. If it's REST, I can stick to our preferred language stack and can make this work.Ģ. Use TeamCity REST API to trigger the agent-build assignment and override the original behaviour given by TeamCity. Currently, TeamCity handles choosing an agent logic based on CPU rank but in our case, we want to use different heuristic which we think it's better for our build pipeline.ġ. We want to take control of triggering the agent - build assignment into our control completely. We don't use any plugins except Slack Notifications. We have multiple build configurations for different projects and for each configuration, we have certain number of build steps which needs to be performed in order. We use the standard teamcity server - agent model provided by you guys.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |