GitHub Actions: reusable workflows is generally available

GitHub Actions keeps getting better and better for teams of all shapes and sizes. Over the past month, thousands of repositories have used the beta of reusable workflows to reduce duplication and increase consistency, including many large enterprises. We’ve released a number of improvements since the beta began in October. This includes output support for passing data from reusable workflows to other jobs, environment secret support, and details about reusable workflows usage in the audit log.

Reusable workflows round out an impressive list of recent features that are aimed at making GitHub Actions scale to teams of any size. In this blog post, I’ll explore three scenarios that have gotten easier with GitHub Actions.

Combine setup, login, and run steps into a single action

Do you find yourself copying and pasting setup or login steps? You can now compose those into a single action. Like any action, these can be used in 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}}

Learn more about action composition

Build consistently across multiple, dozens, or even hundreds of repositories

Do you have a bunch of repositories that are essentially built or deployed the same way? You can now create a reusable workflow, and keep all those repositories in sync.

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

You may want to build a library of reusable workflows, designed to work independently or together. That works too. Use inputs and outputs to pass data between them, just like with actions.

Learn more about reusing workflows

Require specific workflows for production deployments

Do you need to ensure that certain steps are followed for production deployments? You can combine reusable workflows with OpenID Connect, now in beta, to enforce required workflows.

To do this, first define a reusable workflow. For example:

# 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
    …

Then, create a policy in your cloud platform to restrict credentials to just that workflow when it accesses the production environment, as follows:

Subject: repo:shopy/*:environment:production

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

Now, only the deploy_to_production job can access the credentials needed to deploy to production. Also, everyone in your team will need to use the reusable workflow to deploy.

Learn more about using OpenID Connect with reusable workflows

Next up

In the coming months, we’ll ship additional features that help our customers scale to teams of any size. For example, customers who don’t have to deploy to a supported OpenID Connect cloud platform and utilize self-hosted runners will be able to restrict those runners to specific reusable workflows. Enterprise customers will be able to reference actions in internal repositories, removing the need to make them public. And we’ll deliver reusable workflows on GitHub Enterprise Server.

For questions, please visit the GitHub Actions community forum.

Written by

Jennifer Schelkopf

@jenschelkopf