Your code review queue is full again. Builds are stalled because Gerrit’s patch approvals never synced with TeamCity’s pipeline triggers. Somewhere between the review and the CI run, automation tapped out. That’s the classic symptom of a Gerrit TeamCity integration done halfway.
At its core, Gerrit is a powerhouse for code reviews and branch-level governance. TeamCity is a veteran in CI/CD—reliable, detailed, and hard to kill. When they’re wired together correctly, every patch submission can trigger precise builds, gated by real review status instead of human handshakes. Configure the sync right, and your reviewers stop playing “refresh roulette” waiting for results.
Connecting Gerrit and TeamCity starts with events. Gerrit fires patchset-created or change-merged triggers that TeamCity listens for. TeamCity then runs builds by project or label, posting results back to Gerrit as verified or failed. The loop is clean: code review flows into CI, feedback flows back to code review, all without an engineer touching a console. It’s basically review-driven continuous integration.
You’ll want to align identity and permissions early. Map Gerrit accounts to TeamCity users via SSO providers like Okta or AWS IAM so builds and comments stay traceable. Use OIDC tokens or access groups to limit build scripts to the right repositories. Rotate secrets like build tokens quarterly, and lock down injected credentials in TeamCity’s secure storage. These few steps are the difference between an audit-ready CI bridge and one that leaks metadata.
Common setup question: How do I connect Gerrit and TeamCity without plugins?
Use Gerrit’s stream events endpoint as an input feed. Configure TeamCity’s REST API to poll or subscribe for those events, then match patchset IDs with TeamCity build configurations. You don’t need heavy plugins, just clean webhook logic and stable event schemas.