Updated August 2026. This guide now covers Jenkins, Bamboo, and TeamCity in one place, and reflects current Bitbucket Cloud enforcement options.
Jenkins, Bamboo, and TeamCity can all start a build when a commit lands, using repository polling, a VCS trigger, or a webhook from the Git host. All three watch the repository rather than the developer, so they only ever react to a commit that already exists.
None of them can stop it. The build runs on whatever was pushed: commits with no work item key, commits with an unreadable message, commits on a branch nobody approved.
This guide covers both halves of the problem. First, how to wire up an on-commit build in each of the three CI servers. Second, how to make sure the commits that reach your pipeline are worth building.
How CI servers learn about a new commit
Every CI server uses one of two mechanisms, and the choice matters more than the tool.
Polling means the CI server asks the repository for changes on a schedule. It is trivial to configure and requires no access from the Git host into the CI server. The cost is latency and load: with a one-minute poll interval across two hundred jobs, the CI server hits the repository twelve thousand times an hour whether anything changed or not.
Webhooks mean the Git host tells the CI server the moment a push is accepted. Builds start immediately and there is no wasted traffic. The cost is network access: the Git host has to be able to reach the CI server, which is a real constraint when the CI server sits inside a private network and the repository is on Bitbucket Cloud.
| CI server | Native on-commit trigger | Mechanism | Can it reject the commit? |
|---|---|---|---|
| Jenkins | Poll SCM, or Trigger builds remotely | Polling or inbound webhook | No |
| Bamboo | Repository polling, or repository triggers the build | Polling or inbound webhook | No |
| TeamCity | VCS trigger on the build configuration | Polling of the VCS root | No |
| Bitbucket Pipelines | Runs on push, configured in bitbucket-pipelines.yml | Native, in-platform | No |
The last column is the same in every row, and it is the reason the second half of this guide exists.
How to trigger a Jenkins build on commit
Jenkins offers two paths. Use the remote trigger if the Git host can reach Jenkins, and polling if it cannot.
Option A: trigger the job remotely from a webhook
- Open the job and go to Configure → Build Triggers.
- Enable Trigger builds remotely (e.g., from scripts) and set an authentication token.
- In your Git host, add a webhook pointing at the job's build endpoint:
POST https://JENKINS_URL/job/JOB_NAME/build?token=YOUR_TOKEN
- Authenticate the request with a Jenkins username and an API token, sent as a Base64-encoded
Authorization: Basicheader. Generate the API token under the user's Security settings, not the account password. - If the job takes parameters, use
/buildWithParametersinstead of/buildand pass them in the query string.
Option B: poll the repository
- Open the job and go to Configure → Build Triggers.
- Enable Poll SCM and enter a cron expression, for example
H/5 * * * *for roughly every five minutes.
The H prefix spreads the polling of many jobs across the interval instead of firing them all on the same second. On an instance with more than a handful of jobs, use it.
How to trigger a Bamboo build on commit
Bamboo attaches triggers to the plan, and only a Bamboo administrator can configure them. A plan with no trigger can be started manually or as a dependency of another plan's successful build, and nothing else will start it.
- Link the repository to the plan first, under Plan configuration → Repositories. Triggers act on the repositories selected there.
- Open the plan and go to Actions → Configure plan → Triggers → Add trigger.
- Pick the trigger type. Repository polling asks the repository for changes on an interval or a schedule, and works even when Bamboo cannot be reached from outside your network. Repository triggers the build when changes are committed waits for the repository to send Bamboo a message instead, which minimises server load because events arrive only when something actually changed.
- If you chose the push-based trigger, configure your version control system to send those events to Bamboo. This step is already done for you when the plan uses a linked Bitbucket Data Center repository, where it is the default option.
- Save the trigger.
A plan can carry more than one trigger. That is how teams build patterns like every five minutes during office hours and every twenty minutes overnight, using two cron triggers on the same plan.
One cost to weigh before choosing polling: your version control system has to service a checkout or update command every time Bamboo polls, whether or not anything changed, so the load lands on the repository as well as on Bamboo.
If you cut releases from tags, tag triggering is enabled by default as soon as a repository is linked, and works with Git, GitHub, Bitbucket Cloud, and Bitbucket Data Center.
How to trigger a TeamCity build on commit
TeamCity ties the trigger to the VCS roots attached to the build configuration. A build configuration can carry more than one VCS trigger.
- Open the build configuration and go to Triggers → Add new trigger → VCS Trigger.
- Leave the trigger rules empty to build on every detected change.
- Decide how check-ins are grouped. By default, several check-ins detected together produce a single build. Select Trigger a build on each check-in to build every commit separately, or add Include several check-ins in a build if they are from the same committer to group them by author. Per-commit builds make it obvious whose change broke the build, at the cost of agent time.
- Set a quiet period if your team pushes in bursts. TeamCity waits the configured number of seconds after the last detected change before queueing the build, and the timer restarts every time another change arrives. The default is 60 seconds. This stops a build starting halfway through a set of related commits that were pushed as one logical change.
- Save the trigger.
How fast the trigger notices a commit is a property of the VCS root, not the trigger. TeamCity polls on the root's checking for changes interval, 60 seconds by default, and honours a VCS commit hook if you have configured one, which removes the polling delay entirely.
To narrow what starts a build, add trigger rules, one per line:
+:. -:**.md -:lib/** -:comment=minor:**
Each rule is an include (+) or an exclude (-), optionally qualified by user=, root=, or comment= with a regular expression. One behaviour catches people out: the moment you add any + rule, TeamCity flips the implicit default from include everything to exclude everything, which is why the example opens with +:. to put the include-all back. Trigger rules and the branch filter combine with AND, so a commit has to satisfy both.
Should I build on every commit or only on some?
Build on every commit to an integration branch, and use path or branch filters for everything else. All three CI servers support filtering, and it is cheaper to filter at the trigger than to start a build and abort it.
The more useful question is not which commits to build, but which commits should have been allowed into the branch at all.
What a CI trigger cannot check
A CI trigger reacts to a commit that already exists. By the time the build starts, the commit is in the repository's history, it is visible to every other developer, and reverting it means writing a second commit that references the first.
That timing creates a class of problem your pipeline cannot solve:
- A commit with no Jira work item key builds fine. The code compiles, the tests pass, and there is no record of why the change was made.
- A commit message reading
fixbuilds fine. Six months later, during an audit, nobody can reconstruct what was fixed or who approved it. - A commit that references a Jira work item that is already closed builds fine. The link is recorded against work nobody is tracking.
- A direct push to a release branch builds fine, unless someone remembered to configure branch permissions.
Jenkins, Bamboo, and TeamCity are build tools. They verify that code works. They cannot verify that a change was authorized, traceable, or correctly described, because they only ever see the commit after it exists.
JetBrains says the same thing in TeamCity's own documentation, and more bluntly. If a repository is one where untrusted users can push commits, their advice is to not configure a VCS trigger at all and to start builds by hand after inspecting the changes, because the build will otherwise execute whatever those changes contain. That's because a CI server cannot verify a commit, so the only safe option it can offer is to not run.
Bitbucket Cloud cannot close this gap either. It does not support custom server-side hooks, so there is no native place to run a check that rejects a non-compliant push. This is a platform constraint, not a configuration option.
How to validate a commit before the build runs
Better Commit Policy adds the enforcement layer that neither the CI server nor Bitbucket Cloud provides. On Bitbucket Cloud, policies are defined as code in a .commitpolicy.yml file in the repository root, version-controlled alongside the code they govern. On Data Center they are configured in the Jira UI. The rules are the same either way: require a valid work item key, a work item in an allowed status, a message matching an agreed format, or a branch name following a convention. Commits that break the rules are blocked until they are fixed.
To be clear about the division of labour: Better Commit Policy does not trigger builds and does not replace your CI trigger. It decides which commits are allowed to exist, so the builds your CI server triggers run on commits that are traceable.
Enforcement happens at two points.
At commit time, on the developer's machine. A pre-commit hook runs when the developer types git commit, before the commit object is created. A violation costs seconds to fix: rewrite the message and commit again, with the changes still staged.
This enforcement point is unique to the Better Commit Policy apps. No native Bitbucket feature runs a policy check on the developer's machine before the commit is created, and no other Marketplace app does it either. Every other option, including your CI pipeline, reports the problem only once the commit already exists.
At merge time, in Bitbucket. The Commit policy satisfied merge check validates the pull request title, description, and every commit in it, which covers every developer, including those who have not enabled the pre-commit hook. Set as required, a Bitbucket Premium feature, it blocks the merge until the violations are fixed. Set as recommended, available on all plans, it lists the violations without blocking the merge.
On Bitbucket Data Center, the Connector for Bitbucket adds server-side push rejection on top of these, which closes the rebase and force-push bypass paths that Bitbucket Cloud has no hook point for.
Where does this sit relative to my pipeline?
In front of it. The order is: pre-commit hook, then push, then your CI trigger fires, then the merge check gates the pull request. Nothing about your Jenkins, Bamboo, or TeamCity configuration changes.
Does this slow developers down?
It moves the interruption earlier, which makes it cheaper. A missing work item key caught at git commit time is a five second fix. The same violation caught by a blocked pull request involves reviewers, a rebase across several commits, and a re-run of the pipeline.
Why this matters for regulated teams
Under SOX, ISO 13485, IEC 62304, ISO 26262, and similar standards, every change entering a release has to be traceable to an authorized work item. A green build proves the code works. It does not prove the change was approved, and an auditor will ask for the second thing.
Enforcing the work item link at commit time produces that evidence as a side effect of normal development, with no manual reconstruction later.
Get started
Wire up your CI trigger using the steps above, then put a policy in front of it so the commits it builds are ones you can account for.
