I have two agents that can build my configuration.
I've set up two because I sometimes need to do two simultaneous builds.
How can I set build agent priorities to force TeamCity choose specific agent if both are idle and available?
Now it chooses agent randomly or by some unknown factors...
You can filter which agents are used but I'm not sure you can specify which idle to agent to use.
If you are worried about TeamCity using the fastest agent it should do this automatically.
The Teamcity documentation states the following.
When there are several idle agents that can run a queued build, TeamCity tries to select the fastest one as follows:
If no builds have previously run on agents, the CPU rank is used to select an agent.
If builds have previously run on agents, the estimated build duration for the given build configuration is used to select an agent. The estimate is made based on the heuristics of the latest builds in the history of the build configuration; for estimating, the execution time of the more recent builds has more weight than that of the earlier builds. Personal and canceled builds are not taken into account, neither are any individual builds whose duration differs significantly from the rest of the builds for this build configuration.
Now it's possible to configure agent priorities with help of the plugin.
Please enjoy ;)
You can specify that it uses a build agent using the Agent Parameters.
For example you can specify the build agent name (using "system.agent.name") or state that you want to only use build agents with a TeamCity CPU benchmark (say of 400) using: system.teamcity.agent.cpuBenchmark is more than 400.
Related
I have a build configuration consisting of several steps, and I would like to see one specific step fail if it runs longer than a certain time threshold (say, 10 seconds). I don't want to introduce timeout to the entire build (i.e. all steps) which could take several minutes, among other reasons because the time overrun of this specific step should fail the entire build, therefore there is no need to run any subsequent steps.
I know I can implement the timeout feature in a shell or Perl wrapper script reasonably easily; my question is about the TeamCity's support for this feature.
Is there a way to do this via TeamCity build configuration?
I am using TeamCity v7.1
Currently, TeamCity does not support this feature. There is a similar request in our tracker. Although it requests this issue for .Net build runners, it can be expanded to handle other build runner types. You can watch/vote for issue to be notified when it's implemented
I would like my trigger to start on svn commit but only after previous build had finished.
It is implemented to some extent with quiet period but there are disadvantages I'd like to omit:
1. it could be situation build has already finished but we are still waiting for quiet period to finish
2. it could be situation build has not yet finished but we are starting new build because quiet period had finished.
Thanks.
I'm going to assume (since you didn't specify) you want the next build to start only after the previous build has finished because there is some shared resource that they are using (e.g. for integration tests).
TeamCity has a setting to limit the number of simultaneously running builds, whether they are manually run or started by a trigger. Set the following option on the first page (General Settings) of your build configuration to "1":
Limit the number of simultaneously running builds (0 — unlimited)
Edit: TeamCity 8.0 announced today has added support for Shared Resources which allows you to define external resources and quotas for use across more than one build configuration.
We are using bamboo as our integration server. During each build it produces binary packs of our products. Some of the built artifacts then goes in to QA.
Is there a way to retain build artifacts of a certain build job number, irrespective of the global build expire configuration. For an example, at some point we identify one of the built artifacts as release candidate.
The QA should be able to download that specific pack even after one weeks time. Right now we are copying the build artifacts from CI server to some other machine. It is a script, but still it is a manual process.
In Hudson there is an option called 'keep this build forever'.
Depending on your version this is possible by applying a label to it. Under a plan's configuration on the "Miscellaneous" tab, you can set a label which can then be used to prevent a build from expiring.
For example, our system has builds that can get labelled "SaveBuild" which then prevents their expiry.
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.
I have many build configurations in TeamCity, each servicing a large project. In the past if a build is kicked off the Build Agent could be busy for up to 20min!
In order to improve throughput I installed a second Build Agent on the same machine such that if a build run is kicked off by say Build Agent 1 and it is busy for 20min and someone from another project makes a change then Build Agent 2 can do the build for the other project without needing to wait on the current build run to finish.
All was well until two successive check-ins resulted in both Build Agents running a build for a single build configuration in parallel. Since some resources are shared, IIS directories & databases, I don't want a single build configuration to run on both Build Agents in parallel.
How can I ensure a build isn't triggered if a build is currently running for that build configuration on a different build agent?
One way seems to involve environmental variables and ensuring a 50/50 split by Build Agent in terms of build configuration compatibility, but that seems a little clunky.
You can "Limit the number of simultaneously running builds" for a build configuration (general settings page).
Set it to 1, to fulfil your task.