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.
Related
I have a few test sets in a single TFS build definition. I'm looking for a way to run all my tests sets in parallel to cut down on the time that the build takes to run.
Below is a screen shot of my build definition and my automated test configurations.
Does any one know how to accomplish this? I'm not seeing a setting in the build definition and I've seen test setting files being used to set this, but I'm not sure where to set the test setting file in the build definition .
The new vNext build system can run different build configurations in parallel (on different build agents) so you could, but I'm not sure how practical it would be.
Your tests sets would have to be in 4 different projects. Then you'd need to have different configurations:
- anycpu / release-with-tests1
- anycpu / release-with-tests2
- anycpu / release-with-tests3
- anycpu / release-with-tests4
With that you can enable (build) only 1 test project per configuration and set your build to run all tests (*test.dll), each configuration would only run one test project because the other ones were not built.
You enable the parallel build and it runs on up to 4 agents, depending on how many you have. Each agent would have to download the sources and build them before running the tests, so it could be interesting or not depending on how long your tests actually are.
There is a filter for the binaries you want to copy to your drop folder, so you can copy them for only 1 configuration and not waste disk space.
You can use the test frameworks that support multiple threaded execution to run the testing in parallel with multiple cores machines or distribute your test to multiple machines. Refer to this blog from MSDN for details: http://blogs.msdn.com/b/visualstudioalm/archive/2015/07/30/speeding-up-test-execution-in-tfs.aspx
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.
I have a TeamCity (8.0.5) setup running with multiple agents and multiple projects with multiple configurations.
We have some build configurations for CI (eg compile and unit tests) and some of the configurations used for automated deployment.
The deployment configurations run scripts on shared services (eg IIS / sql etc) and so cannot be run in parallel with other deployment builds in any project.
Is there any way to limit this in team city?
I've have seen setting to "limit concurrent builds" but this only applies to a single configuration, I've also tried to limit the deployment builds to single common agent but I haven't been able to do this so far.
TeamCity 8 shipped with the Shared Resources plugin built-in and supported. It allows you to create a Shared Resource on any project in the hierarchy and under Build Features of a Build Configuration you can define what Shared Resources need to be available for the build to run, otherwise it'll be queued until the resource is available and a lock can be taken.
For more information, take at look at the TeamCity documentation: http://confluence.jetbrains.com/display/TCD8/Shared+Resources
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.
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.