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.
Related
We need to setup a snapshot dependency in TeamCity that runs just before the dependant build starts.
Currently we have the problem that the snapshot maybe taken 30 minutes before the build starts. (The build starts later due to other factors). Ideally we want the snapshot to be taken and then the dependant build to immediately start.
Is this possible in TeamCity? Is there another way to achieve a similar thing.
Reading between the lines I'm guessing the problem here is that the dependent build isn't always run immediately when it's snapshot dependency finishes because an agent isn't always available. If that's the case then my suggestion would be to merge the two builds into a single build configuration as that will ensure that all the steps occur with no delay in between.
I have five TeamCity builds that are triggered to run at 01:00. Since they all run on the same Agent, in effect they are queued to run one after the other. Each build takes between 10-60 minutes to complete.
What I'd like to guarantee is that all five builds are run on the same revision. Currently this is not guaranteed because in case a contributing developer can't fall asleep and decides to commit something at 01:30, all builds that start running after that time will run on a different revision.
My question:
Is it possible to configure a build to use a specific VCS revision from a specific time? E.g., configure a build to use the "latest revision at the time of 01:00 today"?
Any other suggestions on how to deal with this problem would be highly appreciated as well.
One of the builds might be set up to have the others as snapshot dependencies. When that build is triggered (e.g. by schedule trigger), its dependencies will be triggered having VCS revision fixed.
Or even new build configuration might be added, it will do nothing except to triggering its snapshot dependencies (your existing configurations).
You can use independent build(or one of a builds will be a master) configuration with trigger at time you need. New config will starts other configs by PS script which calling REST API "Triggering a Build". You can point specified change for all builds(can be get with API "Get pending changes for a build configuration"). This will guarantee all builds will start with same revision. This way might help if dependencies are unacceptable.
We're using TeamCity 9.0.4.
Our full builds take over three hours. While a build is in progress if new commits come in they get queued with, apparently, a VCS snapshot from the time they were queued (I can't see that behaviour specified anywhere, but it's what I've observed).
So by the time the next build is dequeued there may be many builds queued up as developers have been committing changes. The intermediate builds are usually not useful at this point - we just want it to skip straight to the latest build for that configuration.
Other build systems I've used only queue one additional build per configuration and takes its VCS snapshot at the point it is dequeued. This has the effect we want.
I can't work out how to achieve this with TeamCity. What am I missing?
According to our documentation, TeamCity should perform the following build queue optimizations: https://confluence.jetbrains.com/display/TCD9/Build+Queue#BuildQueue-BuildQueueOptimizationbyTeamCity
If it does not work for you, I'd recommend upgrading your server to the most recent version first, and if it does not help, create an issue in our tracker with details about these builds.
I think you've specified this in your trigger.
Edit Configuration Settings | Triggers | VCS Trigger | Show advanced options | Trigger a build on each check-in
That option should be unchecked. The wording is a little confusing I guess. Even with this unchecked, each VCS commit will queue a build but it won't force them to be built in isolation.
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 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.