Reusable delivery workflows

Reuse includes an interface

A reusable workflow gives callers a named set of jobs. Its interface is the inputs it accepts, the permissions it needs and the outputs it returns. This is the same design problem as a small program: a caller should not need to inspect every internal command to use it safely.

Reuse a proven step

Week 1 of the supplementary handbook discusses reusable delivery automation. Apply the idea to MicroBank after its existing image build and offline checks work. A shared workflow helps when several callers need the same tested behavior. Stabilize the process before sharing it.

GitHub Actions reusable workflows can contain jobs and declare inputs through workflow_call. A composite action packages steps within a job. Choose the option that matches what callers need to reuse: whole jobs or steps within a job.

Specify the contract

For a reusable manifest-check workflow, define a finite allowed environment set, the repository revision to inspect, tool versions, and the expected output report. It should render configuration and evaluate policy without cluster credentials. Keep publication and deployment under separate permissions.

For an image-build workflow, define the supported Dockerfile/build-context combinations instead of accepting arbitrary shell text. Retain the artifact's source, platform architecture, digest where published, and test evidence. Pin externally referenced actions and shared workflows to reviewed immutable revisions.

Design a manifest-check interface

Begin with the working local command that renders an overlay. Describe the wrapper before writing GitHub YAML:

An input's string type does not restrict its contents to your two supported environments. Add explicit validation before mapping it to a path. Never interpolate arbitrary user text as a shell command.

Now compare failure cases. Missing overlay directory is an input/content problem. Invalid YAML is a parsing problem. A failed owner rule is a policy problem. Give each a useful report instead of returning a generic “deployment failed,” because this workflow did not deploy anything.

For adoption, start with one caller on a reviewed workflow revision. Change a fixture to an invalid owner and confirm it fails. The next caller should get the same declared behavior, without acquiring publishing secrets merely to reuse checks.

Try it

Write an interface table for one existing MicroBank CI job. Classify every value as input, secret, output, or fixed platform choice. Reject an unsupported service or environment before invoking a build. Do not pass all secrets to a shared workflow merely for convenience.

Review how callers adopt a change: a version bump should come with a diff and compatibility notes. A reusable workflow referenced from a moving branch can change behavior without a consumer PR.

Add offline rendering and policy checks to hosted CI only when proven locally. The periodic synthetic-user scheduler and deliberate failure exercises stay off hosted runners and cloud targets.

Checkpoint and revision

Can a consumer tell what permissions the workflow needs and what its success means? A successful manifest check means only that its declared checks passed; deployment and transaction outcomes need their own evidence.

Compare your reasoning

Use a composite action when you need reusable steps inside the caller's job; use a reusable workflow when you need jobs. Versioning and permissions remain necessary for either. Keep the local synthetic scheduler out of hosted CI even when offline checks move there.

Sources

GitHub workflow reuse↗, GitHub secure Actions use↗.