Set environment and properties for TeamCity build agent. Reconnect. Use them in projectsBy neokrates, written on May 20, 2010 |
 howto |
- neokrates
- Email: uwarov@yahoo.com
- Website: http://www.thinkplexx.com
- Join date: 05-31-09
- Posts: 20
(No Ratings Yet)
Loading ...
Loading ...
-
Since publication, this page was visited 39 time(s).
We start with TC master, two build agents and one project. Perpose is to introduce new system variable, let us call it exclusion.criteria. If it is defined, our project should not use the agent for the builds.
Software:
![[v]](http://www.thinkplexx.com/wp-includes/images/smilies/thinkplexx/set1/OkX16.png)
TeamCity 4.x
Should also work for:
TeamCity 2.x, 3.x, 5.x etc
| 1 |
Add variable
Login to TeamCity agent host.
Then, add new variable into TeamCity agent config file:
vim $TC_AGENT_HOME/conf/buildAgent.properties
add:
system.exclusion.criteria=defined
![[!]](http://www.thinkplexx.com/wp-includes/images/smilies/thinkplexx/set1/warningX16.png)
IMPORTANT Prefix might be either system. or env. Both can be used from the project.
| 2 |
Activate new property. Reconnect the agent
Agent can be reconnected per command line restart, something like:
1 2 3 4 5 6 7 8 | $TC_AGENT_HOME/bin/agent.sh stop Stopping TeamCity build agent... Sending agent shutdown command to: http://localhost:10403 Shutdown command successfully sent. Agent will exit when idle. $TC_AGENT_HOME/bin/agent.sh start Starting TeamCity build agent... Done [1798], see log at ../logs/teamcity-agent.log |
![[i]](http://www.thinkplexx.com/wp-includes/images/smilies/thinkplexx/set1/InfoX16.png)
REMARK. Often, the /etc/init.d/ is used to demonize and configure the agent.
| 3 |
Connect the agent
Agent should appear in TeamCity in Agents -> Connected Agents.
If it is not the case, you might find it in Agents -> Unauthorized Agents
Authorize or activate it.
| 4 |
Setup one build not to build on agents with our property
- Select the project.
- Go to Administration -> Your Project -> You Configuration
- Select Agent requirements
- Under Requirements for system properties, add: system.exclusion.criteria, condition = does not exist
REMARK: You actually enter exclusion.criteria, not _system.exclusion.criteria . Teamcity prefixes itself.
| 5 |
Validate
If done right, the agent with property should switch its location in Agents compatibility
Compatible agents -> Incompatible agents
Thats it, have fun!! 
|
LEARN MORE (amazon bookstore)
|
|
TAGS
|
|
SOCIAL
|
|
[...] 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. 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. If you have large projects, these can be real concerns. 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. [...]
Like or Dislike:
0 
0
Having sticky agents can really help to:
- reduce build time (in many cases no checkout, just update);
- reduce traffic.
I don’t agree that every agent will store working copy of every project. After the builds agents clean the build space and archive what we want them to. There is no difference where we built the project, just Build Log and artifacts will remain.
We have tried to create ’sticky’ build agents, which handle particular class of projects. By doing that we have learned that agents tend to become ’specialized’, which results in problems:
- agents tend to become specialized mainly because people have particular problem with there build and solve it for that agent. Other agents will not be changed. With the time it is both maintainability and update problem.
- one particular result of specialized agents that if we have new project it might require the creation of new agent, because we don’t know the current state of any sticky agent.
- agent state and config cannot be reproduced. If it has problem, many projects just won’t build.
The solution for that ’specialization’ problem was to set the requirement that absolutely no specialized fixes are allowed. Only one builder class, and then allow agent< ->project setup. After that stickiness worked just fine.
Like or Dislike:
0 
0