GitHub Actions for Azure

GitHub Actions is GitHub's built-in CI/CD platform. It allows you to automate workflows directly from your GitHub repository — building, testing, and deploying your applications. GitHub Actions has first-class integration with Azure, making it a popular choice for teams that use GitHub for source control and Azure for cloud infrastructure.

---

GitHub Actions vs Azure Pipelines

Feature	GitHub Actions	Azure Pipelines
Definition	YAML workflow files in .github/workflows/	YAML in azure-pipelines.yml
Source control	GitHub	Azure Repos or GitHub
Marketplace	GitHub Marketplace (20,000+ actions)	Azure DevOps Task library
Runners	GitHub-hosted or self-hosted	Microsoft-hosted or self-hosted
Environments	Environments with protection rules	Environments with approvals and checks
Secrets	Repository, environment, or organisation secrets	Variable groups, Key Vault integration
Matrix builds	Built-in matrix strategy	Built-in matrix strategy
Free tier	2,000 minutes/month (public repos: unlimited)	1,800 minutes/month (1 parallel job)

Both are excellent choices. GitHub Actions is simpler for GitHub-native teams; Azure Pipelines offers deeper integration with Azure DevOps Boards, Artifacts, and Test Plans.

---

Workflow Structure

A GitHub Actions workflow is defined in a YAML file under .github/workflows/:

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read
  checks: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage

Key Concepts

Concept	Description
Workflow	A YAML file defining one or more jobs
Event	What triggers the workflow (push, pull_request, schedule, etc.)
Job	A set of steps that run on a single runner
Step	An individual task — either a shell command or a reusable action
Action	A reusable unit of workflow logic (from the Marketplace or custom)
Runner	The machine that executes the job

---

Authenticating with Azure

Workload Identity Federation (Recommended)

The recommended approach uses OpenID Connect (OIDC) — no secrets to manage:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4

      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - uses: azure/webapps-deploy@v3
        with:
          app-name: 'my-web-app'
          package: './dist'

Setup Steps for Workload Identity

1. Create an App Registration in Microsoft Entra ID
2. Add a Federated Credential for your GitHub repository
3. Assign the App Registration an Azure RBAC role (e.g., Contributor on the resource group)
4. Store the client ID, tenant ID, and subscription ID as GitHub repository secrets

Service Principal with Secret (Legacy)

- uses: azure/login@v2
  with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}

This approach uses a JSON credential with a client secret. It works but requires secret rotation and is less secure than OIDC.

---

Azure-Specific GitHub Actions

Microsoft provides official actions for common Azure tasks: