Reusable Workflows and Composite Actions

# CHAPTER 17

Reusable Workflows and Composite Actions #

1. Introduction #

2. Learning Objectives #

• Define the DRY principle in the context of enterprise CI/CD.

• Understand the difference between Reusable Workflows and Composite Actions.

• Author a central Reusable Workflow in a dedicated repository.

• Call a Reusable Workflow from a "Caller" repository.

• Pass inputs and secrets to centralized workflows.

3. Beginner-Friendly Explanation #

• Without Reusability: The corporate office mails a 50-page recipe book (The YAML file) to all 100 chefs. If corporate decides to change the amount of salt in the soup, they have to mail out 100 new books and hope every chef updates their process.

• With Reusability: Corporate writes the recipe once and puts it on a central, secure website. The 100 chefs simply have a 1-page sticky note that says, "Look at the central website for the soup recipe." When corporate changes the salt, they update the website once. The next day, all 100 chefs make the new soup instantly.

4. Composite Actions vs Reusable Workflows #

1. 1. Composite Actions: You bundle a series of *Steps* together. (e.g., Checkout code, Setup Node, Install Dependencies). You can share this bundle and use it as a single step inside any job.

1. 2. Reusable Workflows: You bundle entire *Jobs* together. You can write a complete "Build, Test, and Deploy" workflow in a central repository, and other repositories can simply "call" it. This is the enterprise standard for centralizing CI/CD.

5. Authoring a Reusable Workflow #

The Centralized File (e.g., company-ops/.github/workflows/central-ci.yml):

name: Centralized CI Pipeline
on:
  workflow_call: # This makes it reusable!
    inputs:
      node-version: # We allow the caller to specify their Node version
        required: true
        type: string
    secrets:
      SLACK_TOKEN: # We require the caller to provide a secret
        required: true

jobs:
  central-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
      - run: npm ci
      - run: npm test

6. Mini Project: Calling a Reusable Workflow #

Step-by-Step Walkthrough (The Caller Repository):

1. 1. Create .github/workflows/app-ci.yml.

1. 2. Paste the following declarative code:

name: Application CI
on: [push]

jobs:
  # We do NOT define runs-on or steps here!
  call-central-workflow:
    # We point to the Organization/Repository/File@Branch
    uses: my-company/company-ops/.github/workflows/central-ci.yml@main
    with:
      # We pass the requested variables to the central script
      node-version: '20.x'
    secrets:
      # We pass the required secrets
      SLACK_TOKEN: ${{ secrets.ORG_SLACK_TOKEN }}

*Look how clean this file is! The developers only manage 13 lines of code. The DevOps team manages the complex logic in the central repository.*

7. Real-World Scenarios #

8. Best Practices #

• Version Control the Central Workflow: Notice the @main in the uses: statement. In a real company, using @main is dangerous. If the DevOps team breaks the central workflow, they instantly break all 100 microservices simultaneously. Always use version tags (e.g., @v1.2.0). This allows applications to upgrade to the new CI process on their own schedule safely.

9. Security Recommendations #

• Access Control: By default, Reusable Workflows can only be called by repositories within the same Organization. Furthermore, inside the Central Repository settings, you can strictly define *which* specific repositories are allowed to call the workflow, preventing rogue repositories from leveraging your centralized infrastructure.

10. Troubleshooting Tips #

• The Nested Limit: You can have a caller workflow call a reusable workflow, which calls *another* reusable workflow. However, GitHub enforces a strict limit: you can only nest up to 4 levels deep. Keep your architecture flat and readable.

11. Exercises #

1. 1. Explain the architectural difference between a Composite Action and a Reusable Workflow.

1. 2. What specific event trigger (on:) must be used to designate a YAML file as a Reusable Workflow?

12. FAQs #

13. Interview Questions #

• Q: You manage GitHub Actions for an enterprise with 500 microservices. Explain how you would utilize Reusable Workflows to enforce a mandatory, standardized security scanning stage across all 500 pipelines without requiring developers to maintain complex YAML logic.

• Q: Contrast the operational use cases of an Action published to the public GitHub Marketplace versus a private Reusable Workflow. Why might an enterprise prefer the latter?

14. Summary #

15. Next Chapter Recommendation #