Reusing GitHub Workflows and Centralized Processes

It’s almost Friday, so we’ll keep today’s post short.

This week, GitHub officially launched the public beta of reusable workflows. Reusable workflows make it easy to treat a workflow like an Action. It can be referenced and executed from other workflows in the caller’s context. This allows teams to share common patterns, to centralize best practices, and to centralize the development of processes.

Reusable workflows listen for a special event, workflow_call. The workflow must wxist in the .github/workflows folder in order to be invoked. The workflow can also receive inputs. The input syntax is very straightforward, as shown below:

1on:
2  workflow_call:
3    inputs:
4      name:
5        description: 'The name of the caller'
6        default: 'user'
7        required: false
8        type: string

Calling a workflow is similar to an Action, through the uses statement.

1jobs:
2  invoke-workflow:
3    uses: org/repo/.github/workflows/deploy.yml@v1

At the moment, Actions must generally be either in a public repository or in the private repo with the workflows that will use it. Internal repositories cannot host actions ( but that will be changing). This limitation can be challenging, especially for Enterprise users. Reusable workflows add another option: they can be stored in internal repositories and shared within an organization. This can provide a way to centralize workflows and process logic without having to create public repositories. That makes this quite an enhancement!

For now there’s a few documented limitations. For example, a reusable workflow can’t invoke another reusable workflow. Some of these limitations (such as a restriction on callers to access the outputs of a reusable workflow) will be removed when the feature becomes generally available. The docs are frequently updated, so make sure to review them to learn more about resuable workflows.

Have fun playing with the new feature, and happy DevOp’ing!