Creating Reusable Workflows using GitHub Actions

Date published: July 20, 2025

What Are Reusable Workflows?

If you’ve been copying the same GitHub Actions workflow across multiple repositories, you know the pain. I’ve been there—managing dozens of similar workflows, updating each one manually when something changes.

Reusable workflows solve this problem. Think of them as functions in programming—write once, use everywhere.

Here’s what they give you:

• Eliminate duplication: Write your workflow logic once, call it from anywhere

• Scale your processes: Manage workflows centrally across your organization

• Standardize practices: Ensure consistent deployment and security patterns

• Speed up development: Teams focus on features, not workflow setup

Building Your First Reusable Workflow

Let’s start with something practical—a reusable workflow for deploying apps to Azure. This handles the common steps most projects need.

Creating the Reusable Workflow

Create “reusable-azure-deploy.yml” in your shared workflows repository:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

name: Reusable Azure Deployment

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
        description: 'Target environment (dev, staging, prod)'
      app-name:
        required: true
        type: string
        description: 'Application name'

##  Using Your Reusable Workflow

Now any repository can use this workflow. Here's how different teams call it:

### Frontend Team Usage

```yaml
name: Deploy Frontend App

on:
  push:
    branches: [ main ]

jobs:
  deploy-to-dev:
    uses: .github/workflows/reusable-azure-deploy.yml@main
    with:
      environment: 'dev'
      app-name: 'webapp-frontend-dev'
      resource-group: 'rg-frontend-dev'
      build-command: 'npm run build:dev'
      node-version: '18'
    secrets:
      AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Input Validation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string

jobs:
  validate-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Validate environment
        run: |
          if [[ ! "${{ inputs.environment }}" =~ ^(dev|staging|prod)$ ]]; then
            echo "Invalid environment: ${{ inputs.environment }}"
            exit 1
          fi
                    
      - name: Continue with deployment
        run: echo "Environment validated successfully"

Pro Tips

Here’s what I’ve learned from building enterprise-scale reusable workflows:

Version Control Your Workflows

Tag your workflows and reference specific versions:

1
2
3
4
5
6
7
8

# Good: Pin to a specific version
uses: .github/workflows/[email protected]

# Better: Use semantic versioning tags
uses: .github/workflows/deploy.yml@v2

# Avoid: Using main branch directly (unless for testing)
uses: .github/workflows/deploy.yml@main

Start Simple, Scale Gradually

Don’t try to build the perfect workflow on day one. Start with basic deployment steps, then add features like:

• Environment-specific configurations • Matrix builds for multiple environments • Conditional deployments based on branch • Rollback capabilities

Key Takeaways

• Write once, use everywhere: Eliminate workflow duplication across projects

• Centralized updates: Change one workflow, update all projects instantly

• Consistent security: Standardized practices across all deployments

• Faster development: Teams focus on features, not workflow configuration

• Version control: Tag workflows for better change management

Start small with a simple deployment workflow. Build your library gradually. Once you have solid reusable workflows, new project onboarding becomes incredibly fast.

The best part? Teams can get production-ready CI/CD running immediately instead of spending days on workflow setup.

References

• GitHub Actions Documentation • GitHub Reusable Workflow Documentation