I currently have one of my build agents in TeamCity running under a specific user due to one of the build steps. The build agent supports a couple different projects, so I want to add an additional build agent. I have successfully done so, but upon doing so the new build agent starts working, but my older build agent gets disconnected and states "Agent has unregistered." Now I am using the same user to try and run both build agents, so not sure if that is whats causing the issue or not. Both build agents are on the same machine and do have distinct names. I have tried to restart the agents in hope that it would fix itself, but have not been successful.
There are several resources covering setup of multiple build agents on the same machine, you can examine them if you wish.
Here are requirements from official documentation:
The agents are installed in separate directories.
The agents have the distinctive workDir and tempDir directories in the buildAgent.properties file.
Values for the name and ownPort properties of buildAgent.properties are unique.
No builds running on the agents have the absolute checkout directory specified.
Please, make sure that port number is changed, as this is most obvious reason why build agent could be terminated. Also, check that each build agent has its own unique name.
Otherwise, please check each build agent logs and - if it won't be clear -, share error here.
Related
I've recently installed TeamCity 2017.2.3 (build 541047) and Octopus Deploy 2018.1.5 and originally was having success running builds and creating packages in TeamCity, but now my build agent shows all of my build steps as incompatible after a service restart.
I've uninstalled and reinstalled the buildagent, plugins (I use Node.JS build runner, Octopus Deploy integration, and xUnit) and rebuilt each of the build steps, but still run into the same problem
Build Step List
Anyone know what would be causing this issue?
Each agent should have a list of global parameters that are picked up from the OS or manually configured from the agent properties file on the machine. These are things like the path, dotnet versions, npm etc.
http(s)://<tc root>/agentDetails.html?id=<agent id>&tab=agentParameters
(You can get to the above by clicking on the agent you want to inspect)
You can then override or add to these from the root project all the way up the project tree to the build configuration.
The message you are getting is saying is that in order for the build to run it needs to have an agent with those parameters configured. Could you give a screen grab of what your build agent parameters are.
Here is an example from one of my build agents which shows some of the configuration parameters that you need.
You should not need to add these, they should be picked up automatically by the agent.
First make sure these dependencies are actually installed.
If missing install and restart the agent service (required to pick up new configuration properties).
Possibly try a machine restart in case newly installed components require a reboot.
Failing that check to see what permissions the build agent service is running under. It might not have permissions needed to poll the system but I have never seen that.
I have the following set-up:
TeamCity server running on one machine
TeamCity agent on a separate machine, connected via VPN to source control (TFS).
The VPN is a bit tricky to set up to run as a service so can't/don't want to set it up on the server as well. Rather, I was hoping to have everything go through that agent.
The build server fails while collecting sources, it appears it's trying to figure out what changes were performed in TFS (but it can't find the TFS host since it's not on that VPN). The build is set to check out the sources only on the agent.
I'm afraid the answer is obvious, but couldn't find any documentation confirming this...Is it possible to have such a setup? Or does the build server need access to the TFS repo to check for changes and trigger builds?
The TeamCity server will still require access to the VCS root to evaluate the current revision and changeset details.
It's important to note the additional side-effects of agent side checkout as well. See VCS Checkout Mode in the TeamCity docs for more information (note the 2nd line).
I would like a module to be run by all agents when a VCS trigger condition is met.
Is this possible?
One way you can do this is by adding a Schedule Trigger which has an option to run on all agents.
Having looked into it, as far as I can see, not directly,
the behaviour could potentially be achieved by using the command line remote runner plugin,(http://confluence.jetbrains.net/display/TW/Command+Line+Remote+Run+Tool) through a seperate build configuration linked to the VCS to detect the changes, calling the Remote Run tool from a command line build step to build the project on each required agent.
Further research into the Command Line Remote Run tool would be required to confirm this is possible.
There may also be some functionality allowing this in the REST API, although my look through the documentation didn't show anything up.
Have you had much luck working on alternative solutions?
I've created a build configuration to update our source managed third party referenced assemblies directory and this is a snapshot dependency on most if not all build configurations. When I update this directory with a new or more recent assembly, I'll too would like this configuration to be run on all build agents.
At the moment, I've simply duplicated the configuration and bound each to a specific agent. It adds management overhead, but has temporarily resolved the issue.
You could install this plugin and specify the list of agent names and it will run once per "value" in the matrix.
https://github.com/presidentio/teamcity-matrix-build-plugin
Our busy enterprise server has 550 active build configurations running on 30 agents. We need a way to prevent some builds from running while other builds are running. I already understand artefact dependencies and this does not solve our problem as the builds do not depend on each other they just share some resources like server port numbers and database connections. Some build configurations conflict with each other when run simultaneously and we need to prevent this by having a way to queue a build (rather than run it) when one of a number of other builds are running.
We already use dumb tricks like restricting builds to specific agents, etc... I'm thinking about adding a first build step that checks for a flag in a db table or something but this would add lots of failed builds when what we really need is proper build queueing.
Am I missing something? Does this functionality already exist in TeamCity?
It looks like what you need is on its way in the form of TeamCity 8 Shared Resources. You can already get access to the EAP here.
My huge respect for 550 configurations and 30 agents.
I think you already found the solution:
Have one environment per agent
Assign configuration for specific agents
I could imagine how much it is work. But I think it's much cleaner and will work much faster than restriction to run several configurations at the same time.
Coming "from" TFS and using TeamCity in a customer project....
...is there a way to install multiple agent instances on one computer? I could easily do that with TFS.
The reason is that we have build scripts that are linear in execution for some (large) part and take a significant amount of time. Basically with a a modern server (4, 6, 8, 12 cores) there is nothing stopping the server from actually efficiently running multiple builds AT THE SAME TIME - except there seems to be no way to install multiple agent instances on one machine.
Yes it is possible (I also have 2 agents installed on one machine) see TeamCity docs:
Several agents can be installed on a single machine. They function as
separate agents and TeamCity works with them as different agents, not
utilizing the fact that they share the same machine.
After installing one agent you can install additional one, providing the
following conditions are met:
the agents are installed in the separate directories
they have distinctive work and temp directories
buildAgent.properties is configured to have different values for name and ownPort properties
Make sure, there are no build configurations
that have absolute checkout directory specified (alternatively, make
sure such build configurations have "clean checkout" option enabled
and they cannot be run in parallel).
Under Windows, to install additional agents as services, modify
\launcher\conf\wrapper.conf to change:
wrapper.console.title,
wrapper.ntservice.name
wrapper.ntservice.displayname
wrapper.ntservice.description
properties to have distinct name within the computer.
More resources:
another question
excellent post