What the heck is the quiet period?
The quiet period is a optional setting on each repository connected to Bamboo. After seeing that a commit has been made to the repo, the quiet period (if enabled) tells Bamboo how long to wait before actually kicking off the build. It lives under the Advanced options in the Linked Repositories configuration screen.
Here’s what the configuration looks like:
Fun Fact! The quiet period was originally invented to cater for the fact that CVS commits are non-atomic. In general, however, it can be used to coalesce multiple commits into a single build regardless of what version control system you’re using.
Why would you want to do that?
The quiet period comes into play if the repository is configured to notify Bamboo when commits are made. If not, and Bamboo is polling the repository for changes, then the quiet period is effectively moot because the polling period acts as a way to coalesce multiple commits into a single build (as the following diagram shows). Note: the diagram is not to scale (imagine the build time is substantially larger in real life). This is one of the rare occasions that polling could be considered useful.
Fig. 1 – No need for the quiet period when Bamboo polls the repo for changes.
The main use case for the quiet period is where you have a long build and you don’t want to deprive other developers who commit changes just moments after yours from boarding the same train (so to speak). Generally you want to avoid long builds, but that’s not always possible. If a build takes a long time (say an hour) and someone commits just after you then they would have to wait almost two hours for their build result. If only the train would wait a few minutes to allow a few people to get on board before starting!
Fig. 2 – Multiple builds triggered by commits in quick succession (bummer if you’re waiting for results from commit #2!)
What about parallel builds of the same plan?
Bamboo’s default setting is to allow only one concurrent build per plan. It’s possible to allow multiple concurrent builds of a plan, but doing so in this instance only kicks the can down the road. For example, if you set the build concurrency to two then it will be third commit that will have to wait for one of those first two builds to finish before it can start. Better to collect the changes of all three committers into the same build.
When do you use the quiet period?
Consider turning on the quiet period for builds that run long (say, over an hour) and are triggered by a call from the repo (as opposed to builds that poll the repo at intervals). The quiet period will hold the build at the station a little bit so that a few more commits can get on the train, thus reducing the turn-around time for the subsequent commits. Since build duration is the largest value here (remember the diagram is not to scale), it is only a small delay for the first committer but a large time saving for the second and third. So overall, it’s a good thing.
Fig. 3 – With quiet time enabled, only one build is triggered for the three commits
Note that setting the quiet period should not be confused with attempts to throttle the server in order to keep the build queue small. Use the concurrent builds setting at the global level (and also overridable at the plan level) for that purpose.
Is the quiet period a new feature in Bamboo?
No. But it’s more important now than ever before.
Prior to Bamboo 5.6, which was released last week, configuring repos to pro-actively call out to Bamboo when a commit is received and trigger a build was, frankly, a bit of a pain. And since it is most relevant in the context of repo-driven build triggers, the quiet period didn’t get a lot of usage amongst our customers.
Now, however, repo-driven build triggers are dead simple when you connect Bamboo to Stash. The notifications for Bamboo are automatically configured as soon as you create your repo in Stash (or, in the case of existing Stash repos, as soon as you link Bamboo and Stash on the back end). So all you have to do is select this as the trigger type in your build plans. Triggering builds this way is far more efficient that spending Bamboo’s CPU cycles on polling repos every few minutes – this is especially true the more repos and build plans you have! So for both these reasons, the quiet period is making some noise (if you will).
Hopefully I’ve inspired you to try out the repo-driven triggers and the quiet period on some of your longer-running builds. Just one small way to make CI more effective when you’re working on a team of developers.
Anyone can be good, but awesome takes teamwork.
Find tools to help your team work better together in our Git Essentials solution.
The post Repo-driven triggers, the quiet period, and you appeared first on Atlassian Blogs.