Practice the key concepts behind reusable GitHub Actions workflows — from workflow_call triggers to matrix fan-out and concurrency control.
0 / 5 completed
1 / 5
During a platform review, the team wants to share a deployment workflow across 12 repos. A colleague asks what trigger enables a reusable workflow. The answer is:
on: workflow_call marks a workflow as reusable. Callers reference it with uses: org/repo/.github/workflows/deploy.yml@main and pass inputs.
2 / 5
A PR comment asks why the matrix job isn't sharing its test results with the caller workflow. You explain that to pass data out of a reusable workflow, you must define:
Reusable workflows expose data via outputs at the workflow level, which map from job-level outputs (set via GITHUB_OUTPUT). Callers read them with needs.called-job.outputs.key.
3 / 5
Your CI runs multiple parallel matrix jobs and hits rate limits. In a standup, you propose adding a concurrency group. What does setting concurrency.group on a workflow achieve?
Concurrency groups serialise or cancel workflow runs sharing the same group key. With cancel-in-progress: true, a new push cancels the previous run on the same branch.
4 / 5
In a code review, a teammate questions whether secrets can be forwarded to a reusable workflow. You confirm they can, using:
The calling workflow passes secrets via secrets: inherit (forwards all) or an explicit secrets map. The called workflow must declare them under on.workflow_call.secrets.
5 / 5
A DevOps engineer asks how to fan out a build across Node 18, 20, and 22 in a reusable workflow that accepts a version list. The correct approach is to define the versions as an input of type:
Pass the matrix values as a JSON-encoded string input (e.g. '["18","20","22"]') and use fromJson(inputs.versions) in the matrix block of the called workflow.