Easiest method to Trigger Azure DevOps pipeline (CI) from Bitbucket?

Question

we have all our pipelines on Azure DevOps:

...but we are using a Repo from another team and it is on Bitbucket Server (company owned). We have our own branch there on the bitbucket repo we use, and I would like to be able to merge PRs to this bitbucket repo and have it "trigger" the Azure (build) pipeline. I am currently just running it manually but it is very tedious. Also, this is on a Bitbucket Server that my company owns (not the regular bitbucket cloud (public) so we have our own custom domain name i.e. www.bitbucket.MY-COMPANY-NAME.com). I tried using the built-in feature on Azure devops (CI) build pipeline to link to the bitbucket repo to trigger "Scheduled" builds at 12AM at night but it always fails for this message:

An exception occurred while polling the repository. Error:
 Microsoft.TeamFoundation.Build2.Server.Extensions.ExternalConnectorException: No references received in
 the response from https://bitbucket.MY-COMPANY-NAME.com/scm/some-repo/some-repo.git/info/refs?
service=git-upload-pack. Status: 502, Reason: Bad Gateway at
 Microsoft.TeamFoundation.Build2.Server.Extensions.GitConnector.ReadRefs(IVssRequestContext
 requestContext, HttpResponseMessage response) in
 D:\v2.0\P1\_work\1\s\Tfs\Service\Build2\Extensions\SourceProviders\Git\GitConnector.cs:line 318 at
 Microsoft.TeamFoundation.Build2.Server.Extensions.GitConnector.GetBranches(IVssRequestContext
 requestContext, ExternalConnection connection, Int32 timeoutSeconds, Boolean useAnonymousAccess) in
 D:\v2.0\P1\_work\1\s\Tfs\Service\Build2\Extensions\SourceProviders\Git\GitConnector.cs:line 125 at
 Microsoft.TeamFoundation.Build2.Server.Extensions.GitSourceProvider.GetMatchingBranchRefs(IVssRequestCont
ext requestContext, BuildDefinition definition, IList`1 branchFilters) in
 D:\v2.0\P1\_work\1\s\Tfs\Service\Build2\Extensions\SourceProviders\Git\GitSourceProvider.cs:line 463 at
 Microsoft.TeamFoundation.Build2.Server.Extensions.GitSourceProvider.GetSourceVersionsToBuild(IVssRequestC
ontext requestContext, BuildDefinition definition, List`1 branchFilters, Boolean batchChanges, String
 previousVersionEvaluated, Dictionary`2& ciData, String& lastVersionEvaluated) in
 D:\v2.0\P1\_work\1\s\Tfs\Service\Build2\Extensions\SourceProviders\Git\GitSourceProvider.cs:line 369 at
 Microsoft.TeamFoundation.Build2.Server.Extensions.BuildPollingJobExtension.Run(IVssRequestContext
 requestContext, TeamFoundationJobDefinition jobDefinition, DateTime queueTime, String& resultMessage) in
 D:\v2.0\P1\_work\1\s\Tfs\Service\Build2\Extensions\BuildPollingJobExtension.cs:line 98.

No logs available for this run

Answer 1

According to Microsoft's document Build on-premises Bitbucket repositories:

If your on-premises server is reachable from the servers that run Azure Pipelines service, then:

• you can set up classic build and configure CI triggers

If your on-premises server is not reachable from the servers that run Azure Pipelines service, then:

• you can set up classic build pipelines and start manual builds
• you cannot configure CI triggers

YAML pipelines do not work with on-premises Bitbucket repositories.

PR triggers are not available with on-premises Bitbucket repositories.

And here is a document that provides some troubleshooting advices about failing triggers:

• Is your Bitbucket server accessible from Azure Pipelines? Azure Pipelines periodically polls Bitbucket server for changes. If the
  Bitbucket server is behind a firewall, this traffic may not reach
  your server. See Azure DevOps IP Addresses and verify that you have
  granted exceptions to all the required IP addresses. These IP
  addresses may have changed since you have originally set up the
  exception rules. You can only start manual runs if you used an
  external Git connection and if your server is not accessible from
  Azure Pipelines.
• Is your pipeline paused or disabled? Open the editor for the pipeline, and then select Settings to check. If your pipeline is
  paused or disabled, then triggers do not work.
• Have you excluded the branches or paths to which you pushed your changes? Test by pushing a change to an included path in an included
  branch. Note that paths in triggers are case-sensitive. Make sure
  that you use the same case as those of real folders when specifying
  the paths in triggers.