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. But running the following command (in the context of the user in question) populated the required key and the TeamCity build agent was able to start.We use the standard teamcity server - agent model provided by you guys. In my case, the second key was missing, for some reason. ![]() HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\.The wrapper exits immediately if either of the following keys are not present: The error message arises when the wrapper starts up, it pulls all the environment variables from the registry and injects them into the current context for the wrapped-application ( source code with error message here). It seems the TeamCity Build Agent is kicked off by the open-source Java Service Wrapper by Tanuki. There were no files created in C:\BuildAgent\logs, but in C:\BuildAgent\launcher\bin\wrapper.log I found the following error message: FATAL | wrapper | 3 18:00:08 | Unable to access registry to obtain environment variables - The operation completed successfully. ![]() No files are produced in the C:\BuildAgent\logs directory, so I don't think the process is even starting at all. There is nothing in event log except success audits for the account logging in and out, and the service failed to start error (with no further details, exit codes, or stack traces).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |