GitHub Integration, YAML Pipelines and Triggers

What it is

A YAML pipeline is a file in the repository that defines when a run starts (triggers), where it runs (pool) and what it does (stages, jobs and steps). Keeping it in the repository means the pipeline is versioned, reviewed and branched with the code.

This topic covers connecting GitHub repositories to Azure Pipelines, writing YAML with the right trigger rules, and designing job execution order with stages, dependencies, parallelism and conditions.

How it works

Connecting GitHub to Azure Pipelines

1. Install the Azure Pipelines app (from the GitHub Marketplace) on the account or repositories, choosing which repositories it can see.
2. In Azure DevOps, choose New pipeline, select GitHub, authorize and pick the repository.
3. Azure Pipelines creates a service connection and a webhook, commits or saves the YAML file, and starts running on events.

Results appear in GitHub as checks on commits and pull requests, so a required status check can block merging. For pull requests from forks, secrets are not made available by default, which protects them from untrusted code.

You can also stay entirely in GitHub with Actions, and deploy to Azure with the azure/login action using OpenID Connect.

Triggers

trigger:
  branches:
    include: [ main, release/* ]
  paths:
    include: [ src/* ]
    exclude: [ docs/* ]
pr:
  branches:
    include: [ main ]
schedules:
- cron: "0 3 * * 1-5"
  displayName: Weekday nightly
  branches:
    include: [ main ]
  always: false

Putting [skip ci] in a commit message skips the CI run. Use path filters so a documentation edit does not start a heavy build.

In GitHub Actions the same ideas are on: push, on: pull_request, on: schedule, on: workflow_dispatch (manual) and on: workflow_call (reusable).

Stages, jobs and ordering

stages:
- stage: Build
  jobs:
  - job: Compile
    pool: { vmImage: ubuntu-latest }
    steps:
    - script: ./build.sh
- stage: Test
  dependsOn: Build
  jobs:
  - job: Unit
    steps: [ { script: ./test.sh unit } ]
  - job: Integration
    steps: [ { script: ./test.sh integration } ]
- stage: Deploy
  dependsOn: Test
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: Prod
    environment: production
    strategy:
      runOnce:
        deploy:
          steps: [ { script: ./deploy.sh } ]

In GitHub Actions the order comes from needs:, and strategy.matrix handles combinations.

Complex and hybrid pipelines

• Hybrid pipelines: build on Microsoft-hosted agents, then deploy through a self-hosted agent that can reach a private network.
• Multiple pools: each job can have its own pool.
• VM templates: pipelines can build virtual machine images (for example with Packer) that become the template for scale set agents or app servers.
• Runtime parameters let someone choose options when they run the pipeline manually.

A worked scenario

A GitHub repository needs a build on every pull request and a nightly full test run. The team installs the Azure Pipelines app, sets pr: to main and a schedules: cron for weeknights with always: false. Build runs first, then unit and integration jobs run in parallel, then a deploy stage with a condition that allows only main and an environment with approvals. A path filter ignores changes under docs/.