![]() ![]() Specifically, in the buildAgent.properties file (in the /conf folder), you can add your own user defined values. So how do you specify that a particular agent should be associated only with a certain set of projects? Through the use of agent environment variables, as discussed here. If you have large projects, these can be real concerns. And each agent will need to have a working copy of every project, which multiplies the disk space needed and the traffic with the VCS server. Having two (or more) build agents is great, but now all that’s going to happen is every project will just get picked up by whichever agent happens to be free. I found that it was preventing me from deleting some services (that I was trying to then recreate). If you don’t modify these, then what will happen is your new agent will give your old agent the boot, as it were, and you’ll still have only one agent running on the machine as a service, but it will be pointing at the new folders you told it to use for the second agent.Īlso, if you find yourself faced with an error when trying to create or delete a service using the scripts for doing so that are included in the agent folders, try closing the services.msc dialog. ![]() ![]() ![]() Make sure you edit the nf file and change the following properties so they are unique among your agents: Read them here.Īssuming you’re on a windows machine, you can go ahead and use the MS Windows Installer. Specifically, there are some notes on things you need to know about installing multiple agents on the same machine. If you click on Administration, you should see a link just below the search bar to Install Build Agents, like this:īefore you do anything, you should read about configuring this new agent! This is the default approach, of course, and is listed only to make you think this is an exhaustive list of options.Īssuming you already have TeamCity set up and running, installing a new agent is pretty simple. This is the approach I’m demonstrating here. These can live on the same server or on different machines. The agent does the real work of building your projects, and you can install multiple agents based on your license of TeamCity. The TeamCity tray notifier can now talk to more than one instance of TeamCity (though I haven’t tried it myself), so this would be one option if you have the hardware available.Īdd another build agent. Beyond the frustration, this causes a very real and negative impact on your productivity.Ĭreate another build server. If you were to check in one of these small sites, hoping to quickly see the build server turn green, you would be rather frustrated if your timing were poor and you had to wait 10 minutes for a larger project that was unrelated to your project to finish its build. Let’s further assume that some of these build configurations do a lot of stuff, and thus might take 10 minutes or more to run, while others are for relatively small projects or web sites that might take 30 seconds or less to run. Let’s say you have several large projects and you want them to run on the same instance of TeamCity. I do miss CCTray, which I found to be much nicer than the TeamCity tray notifier (which if you click on it never shows anything immediately – it has to go and get it which imposes a delay – it also doesn’t do sounds like CCTray does – but I digress). Before TeamCity, I was using, and TeamCity is much easier to get working (and requires far less XML manipulation). We’re using TeamCity to manage our continous integration builds for and. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |