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
Related
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.
We have one TeamCity server running on a mac, we have multiple agents running on mac and windows that do different types of builds.
Although the builds themselves are different (build with xcode/build with msbuild), there are a bunch of scripts at the end of each configuration that are the same. They involve copying files to a specific network share, notifying team members, and a few other things.
What would be great is if I could run the platform specific tasks on the respective build agent, but have the actual server run the final scripts after that.
The reason for this is to avoid writing everything in both bash and batch files (I can write it for the server, and make sure it has any dependancies), but also if we wanted to hook up an audio/visual/physical alert for a build fail, the script that runs that should only run on the server (no speakers/lights/nerf cannon on the agents).
Any ideas how I can easily setup a script to run on the server itself, and pass in the properties from the build?
Does this require a plugin, can I do something with the dependancy system, or do I need to delve into the REST API and trigger other configurations that way?
The solution we came to in the end was to use Meta-runners with a Python Runner. This allows us to have cross-platform python scripts that we can setup using the Team City variables. It also allows us to use these scripts in multiple configurations.
If anyone is looking to do this themselves, the platform module in python is useful if you still need to do some platform specific things in your script.
For example the following code allows us to us to use network share paths already setup on the build agents:
if platform.system() == 'Windows':
network_folder = "//server_pc/builds"
else:
network_folder = "/Volumes/builds"
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.
Our team has a full licence for the TeamCity server, as well as 7 additional agents. Another unrelated team has reached the limits of their free TeamCity licence and is eyeing our licences up.
The powers that be think it's a good idea to run both teams using the same enterprise licence, which means that we'd be hosting the TeamCity configurations on the same server, and either sharing agents or somehow assigning some agents to one team, some to another.
One concern I have is that configuring an agent to only accept certain builds is difficult - our team has hundreds of build configurations, and we create new ones all the time. To limit an agent to certain builds, you have to fully specify the whitelist. So maintaining the agents such that we have full use of some agents, and the other team has full use of theirs will be a pain. On the other hand, just using one pool of agents means now you have arguments over priority and starvation, etc.
Does anyone have any experience of this? Is it a workable solution? How do you configure agents to reserve them for a particular team? How do you configure the server so that each team only sees their own projects, build configurations and agents? Basically what we'd want is complete separation of the projects, just using the same TeamCity server and agents.
As a gut feeling it doesn't look like a good idea...
edit: As an aside, does Hudson do this better? The ivory tower architects want us to change from TeamCity to Hudson because other people are using Hudson. If I tell them this sharing TeamCity won't work, the Hudson camp will probably use it as a stick to beat us with. Joy.
Not sure what version of TeamCity you're using but the newly released TeamCity v7.0 now has a new Agent Pool feature that provides a much easier way to distribute agents. It may be of interested to you, check out the What's New section or the Agent Pools docs for more info.
I had a similar issue with our two departments starting to share the same TeamCity instance to save the expenses of additional licenses. I must admit we didn't really have any issues apart from our agents were now twice as busy.
I enabled Per-project permissions on the Global Settings page and created 2 user groups, one for 'us', and the other for 'them'. You can then configure each group's roles accordingly. If a group does not have the Project Viewer role for a project then it does not appear for them - a great way to only display necessary projects to the group; but there are plenty of other role options to use.
I have never used Hudson so can't compare unfortunately. I should really try it out but as I've always got on so well with TC I've never had a reason too.
You can make builds on run on certain agent, from the build configuration of each build in the agent requirements section, thereby limiting any build configuration to certain agents.
For example if your agent for one team is teamcity1 you can specify:
system.agent.name does not equal teamcity1
So it will never run on that agent.
That way you can at least copy build configurations and they will run on seperate agents without the fiddle agent configuration.
The other team can create a new Teamcity server, and it will have its own new set of free build configurations and agents.
We don't do this any more, but we used to split our agents into pseudo-pools so we could reserve some for compilations and others for automated tests (because automated test jobs can swamp the grid). We added a "can_run_tests" property to the test agents, and made those builds require that property as an agent condition. It worked great, and it's the sort of thing you can bake into the AMI for a set of cloud agents.
What we do now is to make the compilation and test builds require on different AMIs, which does essentially the same thing.
Is it possible to use CruiseControl.Net to set up a build farm? We currently have 4 different build machines building different things at different times and have a bit of a headache to manually balance the load somehow. I would prefer to designate one of them to be the master build machine, which would delegate work to the other ones when they are free.
As far as I can determine, there is no support in CruiseControl.Net for build farms - at least not operating the way you describe. CCNet's interpretation of "farm" seems to assume that projects are assigned manually to a machine and a given project will always be built on the same machine.
If you wanted to dynamically select which machine actually performs the build, you would need to create your own mechanism to select that machine and trigger the build on it. There is likely to be quite a bit of complexity associated with this. For instance you would probably need to ensure that the same project does not get built simultaneously on two different machines if a second commit occurs while the previous commit is still being processed.
If there is a shared location that all the build machines can access, it may be possible to use the Filesystem source control block or CCNet's ForceBuild mechanism to start the build on the designated machine, but have all the build machines publish their output for a given project to the same final location.
See load-Balancing the Build Farm with CruiseControl.NET blogpost for a possible solution