Skip to main content
Creating modular, maintainable CI/CD pipelines is essential for growing codebases. GitHub Actions reusable workflows let you extract common jobs—such as deployments—into standalone workflows that multiple repositories or branches can call. This approach eliminates duplication, reduces errors, and enforces consistent deployment practices across projects.
The image shows a visual representation of a CI/CD workflow with steps for unit testing, code coverage, dependency scanning, application building, and deployment to development and production environments.
The diagram above depicts a typical CI/CD pipeline for a Node.js application:
  1. Unit Testing
  2. Code Coverage
  3. Dependency Scanning
  4. Build
  5. Deploy to Dev (runs after build succeeds)
  6. Deploy to Prod (waits for Dev deployment)
Each deployment job consists of five granular steps (e.g., environment setup, artifact upload, feature flag toggles, smoke tests, notifications).

​
Why Use Reusable Workflows?

Imagine your organization maintains services in Java, Python, .NET, Go, and more. While build and test commands differ, deployment steps—like provisioning infrastructure, uploading artifacts, and running smoke tests—tend to be identical. Reusable workflows centralize these shared steps: By extracting deployment logic into its own workflow, you avoid copy-pasting nearly identical YAML across repositories. Instead, each app’s pipeline can call the reusable deployment workflow.

​
1. Extracting the Deployment Job

Let’s say you have a repository xyz-org/nodejs-app-repo with .github/workflows/awesome-app.yml:
To DRY-up your CI/CD, move the dev-deploy job into its own reusable workflow file:
The on: workflow_call trigger makes this workflow callable from other workflows. You can also define inputs, outputs, and secrets under workflow_call for advanced parameterization.

​
2. Calling a Reusable Workflow

Back in awesome-app.yml, replace the inline dev-deploy job with a reference to the reusable workflow:
If the reusable workflow lives in another repository, reference it by {owner}/{repo}/{path}@ref:
When calling workflows in private repositories, ensure the caller has appropriate permissions and that any required secrets: are declared in the called workflow’s workflow_call section.

​
3. Inputs, Outputs, and Secrets

To make your reusable workflows more flexible:
  • Inputs allow callers to pass parameters (e.g., environment name, version tag).
  • Outputs let callers consume results (e.g., artifact URLs, deployment IDs).
  • Secrets ensure sensitive data—like cloud credentials—are never exposed.
Example of declaring inputs and secrets in a reusable workflow:

​
Benefits of Modular CI/CD with Reusable Workflows

  • Consistency: Enforce the same deployment steps across all services.
  • Maintainability: Update a single workflow file to propagate changes everywhere.
  • Scalability: Easily onboard new projects by referencing prebuilt workflows.
  • Security: Centralize and manage secrets in one place.

Watch Video