Source code lives in a "GitHub" repository, but the team builds and deploys using "Azure Pipelines". They need a pull request that targets the main branch to automatically queue a validation run, and the run's pass or fail status to appear as a check on the pull request. Which integration should they configure?
- AAdd a scheduled trigger to the YAML pipeline that polls the repository every few minutes, so any open pull request is eventually picked up and validated by Azure Pipelines.
- BConnect the pipeline to the repository through the "Azure Pipelines" GitHub App and define a pull request trigger on main, so each pull request queues a run and reports its status as a check. Correct
- CMirror the repository into Azure Repos and run branch policies there, then have developers raise their pull requests in Azure Repos instead of in the GitHub repository.
- DStore a personal access token in the pipeline and have a build step call the GitHub status API after each manual run to post a result onto whichever pull request is open.
Why A is wrong: A schedule runs on a clock rather than per pull request, introduces delay, and never reports a status check back onto the specific pull request as required.
Why B is correct: The GitHub App integration installs webhooks and check permissions, so a pull request trigger queues a run automatically and the result surfaces as a status check on the pull request.
Why C is wrong: Mirroring relocates the workflow away from GitHub where the code lives, duplicates the repository, and does not satisfy the need to validate pull requests in the GitHub repository itself.
Why D is wrong: Hand-rolling status updates with a stored token is fragile, relies on long-lived secrets, and still lacks an automatic per-pull-request trigger from the native integration.