Integrating GitHub repositories with Azure Pipelines
Design and implement integration between GitHub repositories and Azure Pipelines
Two authentication types, and only one is recommended
| Type | Runs as | Recommended |
|---|---|---|
| GitHub App | The Azure Pipelines identity | Yes |
| OAuth | Your personal GitHub identity | No |
The GitHub App is the recommended type for CI. Once installed, builds and status updates are performed as Azure Pipelines rather than as a person — so a pipeline does not break when that person leaves, and the audit trail names the service. It also integrates with GitHub Checks to surface build, test and coverage results in the pull request.
Scope it deliberately. Installing the app for all repositories in an organisation gives its token access to all of them, including private ones. Microsoft's guidance is to separate public and private repositories at the organisation level, or to explicitly select the repositories the app may access.
Forks are the security boundary
By default, secrets associated with your pipeline are not made available to pull request validations from forks. Fork PRs do trigger validation builds automatically, but they run without your secrets.
That default is correct and you should think hard before changing it: a fork PR contains code written by someone outside your organisation, and any step it adds would run with whatever credentials you expose. The toggle lives under Triggers → Build pull requests from forks of this repository.
Primary sources