GitHub Actions: reusable workflows is generally available

Reusable workflows in GitHub Actions are now generally available, following a beta that began in October and was exercised by thousands of repositories, including many large enterprises. Outputs for passing data from a reusable workflow to other jobs, environment secret support, and usage details in the audit log all landed during the beta period.

Composite actions: fewer copy-pasted setup steps

Setup and login steps that teams previously duplicated across jobs can be folded into a single action, which then works wherever an action does — across multiple jobs and workflows, and published to GitHub Marketplace.

Before

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: docker/setup-buildx-action@v1
      - uses: docker/login-action@v1
        with:
          username: ${{inputs.registry_username}}
          password: ${{inputs.registry_password}}
      - uses: docker/build-push-action@v2
        with:
          context: .
          push: true
          tags: user/app:latest

After

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: my-org/publish-docker@v1
        with:
          registry_username: ${{secrets.REGISTRY_USERNAME}}
          registry_password: ${{secrets.REGISTRY_PASSWORD}}

One workflow definition across many repositories

Repositories built or deployed in essentially the same way can be kept in sync through a single reusable workflow.

Before

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [10.x, 12.x, 14.x, 15.x]

    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v2
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

After

jobs:
  build:
  uses:
    my-org/actions/.github/workflows/node.js.yml@1

A library of reusable workflows is also possible, with each workflow designed to run on its own or together with others. Data moves between them through inputs and outputs, the same mechanism actions use.

Locking production deploys to an approved workflow

Reusable workflows pair with OpenID Connect — currently in beta — to enforce which steps a production deployment must go through. The first step is defining a reusable workflow:

# shopy/app/.github/workflows/release.yml

name: Build and release
on: [push, pull_request]

jobs:
  cd:
    uses: shopy/actions/.github/workflows/cd.yml@1

# shopy/actions/.github/workflows/cd.yml

name: CD
on: [workflow_call]

jobs:
  deploy_to_review:
     ...

  deploy_to_staging:
     ...

  deploy_to_production:
    environment: production
    …

A policy in the cloud platform then limits credentials to that workflow when it touches the production environment:

Subject: repo:shopy/*:environment:production

Custom claim: job_workflow_ref:
shopy/actions/cd/.github/workflows/cd.yml@1

With both pieces in place, only the deploy_to_production job can obtain the credentials needed for production, and team members must deploy through the reusable workflow.

On the roadmap

• Self-hosted runner customers without a supported OpenID Connect cloud platform will be able to restrict those runners to specific reusable workflows.
• Enterprise customers will be able to reference actions in internal repositories without making them public.
• Reusable workflows are coming to GitHub Enterprise Server.