Github Actions by Example
  • GitHub Actions by Example
  • chap1-intro
    • Section 1 - Introducing GitHub Actions
    • Section 2 - Terminology and Core Concepts
    • Section 3 - Building a workflow
  • chap2-deployment-workflow
    • Section 1 - Workflow
    • Section 2 - The services
    • Section 3 - The test workflow job
    • Section 4 - The build and push workflow job
    • Section 5 - The deploy workflow job
  • Chap3-reusable-workflows
    • Section 1 - What is a reusable workflow
    • Section 2 - The test reusable workflow
    • Section 3 - The build and push reusable workflow
    • Section 4 - The deploy reusable workflow
    • Section 5 - Releasing the reusable workflow
  • Chap4-custom-actions
    • Section 1 - What is a custom action
    • Section 2 - Composite Custom Actions
    • Section 3 - Javascript Custom Actions
Powered by GitBook
On this page
  • Creating a reusable workflow
  • Where do reusable workflows live?
  1. Chap3-reusable-workflows

Section 1 - What is a reusable workflow

A reusable workflow allows us to define a workflow that can be called from another workflow. We can think of it as a function. For example, referencing the deploy workflow we created in the previous chapter, if we define it as a reusable workflow, we won't need to define the workflow in each repository that requires it. Instead, we can call the reusable workflow with some given inputs.

...
jobs:
  deploy:
    uses: SamirMarin/github-by-example-reusable-workflows/.github/workflows/reusable-deployment.yaml@deployment-v0
    with:
      name: example-service
    secrets: inherit

Instead of defining the deploy workflow in each repository, as we did in Chapter 2 for the workout-management-service and user-management-service, we can define it once and call it from each repository that needs it.

Creating a reusable workflow

Let's jump right into what it takes to define a reusable workflow to make the concept clearer.

First, all reusable workflows must be defined with:

on:
  workflow_call:

Inputs

Since reusable workflows are like functions, they can take inputs. Inputs give us control over how to differentiate between the different workflows that call the reusable workflow.

on:
  workflow_call:
    inputs:
      name:
        required: true
        type: string
        description: "The service name"

We can also pass secrets into a reusable workflow. We must place these under secrets.

on:
  workflow_call:
    inputs:
      name:
        required: true
        type: string
        description: "The service name"
    secrets:
      docker-secret:
        required: true

At this point, we can start defining the workflow as we would define any regular workflow, with the difference that we define the workflow with a workflow_call trigger and the inputs/secrets passed by the calling workflow.

name: Print Info

on:
  workflow_call:
    inputs:
      name:
        required: true
        type: string
        description: "The service name"
    secrets:
      docker-secret:
        required: true

jobs:
  print-passed-info:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Print Name
        run: |
          echo The service is ${{ inputs.name }}
      - name: Print Info
        run: |
          echo ${{ secrets.docker-secret }} this value does not show because it is a secret.

Where do reusable workflows live?

Reusable workflows can live anywhere. For example, you can define them in the same repository that calls them. However, since the goal is to reuse these workflows across multiple repositories, we will define them in a separate repository.

Let's create a new repository called github-by-example-reusable-workflows. In the next section, we will start defining the workflows we created in Chapter 2 as reusable workflows.

PreviousChap3-reusable-workflowsNextSection 2 - The test reusable workflow

Last updated 8 months ago