What's changed: New GH-200 Chapter 2 (interpreting/troubleshooting = triggers/status, logs/annotations/run history, ACTIONS_STEP_DEBUG, YAML anchor expansion, reading matrix and re-running individual jobs, fetching logs/artifacts via UI/API; templates & reuse = starter vs reusable workflows vs composite actions, org/non-public templates, disabling vs deleting)
2.2Templates and Reuse — Starter, Reusable Workflows, and Composite Actions
Understand org-level workflow templates (starter workflows) vs reusable workflows (workflow_call), using non-public (organization-internal) templates, the differences among starter workflows, reusable workflows, and composite actions, and the difference between disabling and deleting workflows.
To avoid rewriting the same pipeline, GitHub offers several reuse mechanisms, and GH-200 tests their differences and when to use each. The most commonly confused are starter workflows, reusable workflows, and composite actions. The crux is whether you copy a scaffold and become independent, call a central definition, or bundle steps into an action.
2.2.1The three reuse mechanisms
A starter workflow is a scaffold (template) for creating a new workflow. Placed in an organization’s .github repo, members can pick and copy it from the "new workflow" screen. After copying it is independent—changing the original does not propagate (it’s for the initial scaffold). A reusable workflow is a central definition with on: workflow_call that callers reference via uses:; updating the original flows to callers (per the referenced ref), acting as a versioned single definition. A composite action bundles multiple steps into a single action, invoked as one step (uses:) in a workflow.
| Mechanism | What it is | Update propagation | Invocation |
|---|---|---|---|
| Starter workflow | Scaffold for new workflows | Independent after copy (no propagation) | Copy from UI |
| Reusable workflow | Central on: workflow_call definition | Propagates per referenced ref | uses: an entire workflow |
| Composite action | An action bundling steps | Propagates per referenced ref | uses: as one step |
2.2.2Consuming org-level and non-public templates
Organizations can share starter and reusable workflows internally (non-public). Put starter workflows under workflow-templates in the org’s .github repo for members to choose. For reusable workflows in private repos within the org, enable access (sharing) settings so other repos can call them. This distributes and governs internal standard pipelines without making them public.
2.2.3Disabling vs deleting workflows
To stop a workflow, disable and delete differ. Disabling temporarily halts runs while keeping the workflow file, and you can re-enable it from the UI (ideal for maintenance or pausing). Deleting is destructive to the file/history and requires recreation to restore. Use disable for "pause for now" and delete for "no longer needed."
Common: (1) starter workflow = scaffold for new workflows (independent after copy, no propagation), placed in the org .github repo under workflow-templates. (2) reusable workflow = central on: workflow_call definition called via uses: (propagates, versioned). (3) composite action = an action bundling steps (used as one step via uses:). (4) Non-public org sharing requires access settings. (5) Pause = disable (re-enableable); remove = delete.
Watch out: (1) Starter workflows are copied and independent—editing the original doesn’t reach each repo (use a reusable workflow for central updates). (2) Don’t conflate reusable workflows (call a whole workflow) with composite actions (one step). (3) Disabling halts runs but keeps the file—don’t confuse with deletion. (4) Non-public reuse requires enabling access (sharing) settings.
2.2.4Section summary
- Starter workflow = scaffold for new workflows (independent after copy), distributed via the org .github repo
- Reusable workflow = central on: workflow_call definition called via uses: (propagation, versioning)
- Composite action = an action bundling steps (used as one step)
- Non-public sharing needs access settings; pause via disable (re-enableable), remove via delete
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to manage standard CI logic in one place so that updates reach all referencing repos. Which mechanism do you use?
Q2. You want to provide a "starting scaffold" org-wide for teams creating new workflows. Which fits?
Q3. You want to bundle the repeated "setup → build → cache" steps into one reusable unit used as a single step in workflows. Which fits?
Q4. You want to temporarily stop a workflow during maintenance and restore it later (keeping its file/history). What do you do?
Q5. What is needed to let another repo call a reusable workflow that lives in a private repo within your organization?
Q6. Which correctly states the essential difference between starter workflows and reusable workflows?