Skip to content

Chapter 7 of 7

Reusable Workflows, Environments, and Deployments

GitHub Actions supports reuse at two levels. Within a single workflow, an action invoked at the step level with uses: is a reusable unit of work, with inputs passed through with: and outputs referenced through steps.step_id.outputs. Across workflows, a reusable workflow is invoked at the job level with uses: owner/repo/.github/workflows/file.yml@ref, allowing whole pipelines to be shared between repositories. A reusable workflow is triggered by the on: workflow_call: event, can declare inputs under on.workflow_call.inputs, and accepts secrets either explicitly through secrets: NAME in the with: block or with secrets: inherit to forward them all from the caller.

Deployments typically use the environment: key on a job, which links the job to a named deployment environment with its own secrets, protection rules, and URL. A deployment protection rule gates deployments to that environment, often requiring manual approval or a passing status check before a production job is allowed to proceed. A common release-driven pattern uses on: release: types: [published] as a trigger, paired with a job using environment: production to publish artifacts once a GitHub Release is created, distinguishing the GitHub Release object (which wraps a git tag with notes and assets) from a plain git tag.

Most language ecosystems have dedicated setup actions that bootstrap the toolchain in a single step. actions/setup-node@v4 with node-version: '20.x' installs Node.js, actions/setup-python@v5 with python-version: '3.12' installs Python, actions/setup-java@v4 with distribution: 'temurin' and java-version: '21' sets up a JDK, and actions/setup-go@v5 with go-version: '1.22' cache: true installs Go with automatic module caching. These actions, like actions/checkout, are best pinned to a full-length commit SHA in production workflows rather than to floating tags like @v4 or branches like @main, which trade stability for convenience. When pinning third-party actions, the recommended pattern is uses: owner/action@full_commit_sha, ensuring that updates to the action cannot silently change your pipeline behavior.

All chapters
  1. 1GitHub Actions Foundations
  2. 2Triggering Workflows
  3. 3Jobs, Matrices, Concurrency, and Conditions
  4. 4Environment Variables, Outputs, and Context References
  5. 5Permissions, Tokens, and Security
  6. 6Artifacts, Caching, and Service Containers
  7. 7Reusable Workflows, Environments, and Deployments

Drill it

Reading is not remembering. These come from the Github Actions Ci Cd Recipes deck:

Q

What is GitHub Actions?

A CI/CD and workflow automation platform built into GitHub that runs jobs in response to repository events using YAML-defined workflows stored in .github/workfl...

Q

What file extension do GitHub Actions workflow files use?

.yaml or .yml, stored under .github/workflows/ in the repository.

Q

What is a workflow in GitHub Actions?

An automated, configurable process defined by a YAML file that runs one or more jobs and is triggered by events.

Q

What is a job in GitHub Actions?

A set of steps in a workflow that execute on the same runner; jobs run in parallel by default unless dependencies are declared with needs:.