How do you trigger Azure DevOps pipelines from GitHub, Bitbucket, or external webhooks?

Think of external triggers like different doorbells connected to the same house intercom. GitHub triggers are like a dedicated smart doorbell with video and two-way communication — rich integration with status checks and PR comments. Bitbucket triggers are similar but with a different brand of doorbell. Generic webhooks are like a simple button wired to the intercom — any visitor can press it, but you only get a basic notification without the fancy features. Each doorbell connects through a different mechanism but ultimately triggers the same response: the pipeline runs.

GitHub integration is the richest external trigger experience. You create a GitHub Service Connection in Azure DevOps using OAuth or a Personal Access Token, then reference the GitHub repository in your pipeline YAML. The trigger section works identically to Azure Repos triggers — branch filters, path filters, and batch settings all apply. For pull requests, Azure DevOps automatically posts build status checks on the GitHub PR, and you can configure branch policies in GitHub that require the Azure DevOps build to pass before merging. The integration supports GitHub Apps for organization-wide access or OAuth for individual repository access.

Bitbucket integration follows a similar pattern using a Bitbucket Cloud Service Connection. You authorize Azure DevOps to access your Bitbucket workspace, then reference the Bitbucket repository in the pipeline resources section. CI triggers fire on branch pushes, and PR triggers fire when pull requests are created or updated. Azure DevOps posts build status back to Bitbucket for visibility. The main limitation compared to GitHub is that Bitbucket Server (self-hosted) requires additional networking configuration to allow Azure DevOps to reach the Bitbucket API.

Generic webhook triggers enable any external system to trigger a pipeline. You define an incoming webhook service connection in Azure DevOps with a unique name and optional shared secret for request validation. External systems send HTTP POST requests to a generated webhook URL, and the pipeline fires when the request matches configured filters. The webhook payload is available in the pipeline as JSON that you can parse to extract information like the triggering event type, branch name, or custom metadata. This enables integrations with systems like ServiceNow (trigger deploy after change approval), Jira (trigger pipeline when ticket moves to Ready), or custom internal tools.

Multi-repository triggers allow a pipeline to respond to changes in multiple repositories simultaneously. Using the resources.repositories section, you declare external repositories (GitHub, Bitbucket, or other Azure Repos) and configure triggers on each. When any declared repository has a matching commit, the pipeline triggers and checks out all declared repositories into the workspace. This enables mono-pipeline patterns where a single pipeline builds code that spans multiple repositories, or infrastructure pipelines that trigger when either application code or infrastructure definitions change regardless of which repository they live in.

The production gotcha is webhook security and reliability. Generic webhooks accept HTTP requests from any source unless you validate the shared secret in the payload header. Without secret validation, anyone who discovers the webhook URL can trigger your pipeline, potentially deploying malicious code or exhausting build minutes. Always configure the shared secret and validate HMAC signatures. Another issue is webhook delivery reliability: if the Azure DevOps webhook endpoint is temporarily unavailable, the triggering system's webhook retry policy determines whether the event is lost. GitHub retries failed webhook deliveries for 3 days, but custom systems may not retry at all. Implement monitoring that alerts when expected pipeline triggers do not fire within the expected window.