A team has three workflow steps that each run shell commands: install a CLI, authenticate it, then call it with arguments. They want to package exactly these run steps into one reusable unit that they can publish and call with a single uses: reference, without rewriting the logic in another language or building an image. Which action type should they author?
runs:
using: "<type>"
steps:
- run: ./install.sh
shell: bash
- run: ./auth.sh
shell: bash- AA JavaScript action, because the runner can only execute bundled shell run steps after they are first rewritten as a Node.js entry point that the toolkit invokes on each platform.
- BA Docker container action, because grouping several shell commands into a single action is only supported once the commands are baked into an image that the runner pulls before each invocation.
- CA composite action, because its action.yml uses a runs block with using: composite and a steps list, letting them bundle the existing shell run steps into one unit referenced through uses:. Correct
- DA reusable workflow, because a file under .github/workflows called through workflow_call is the supported way to package shell run steps for reference by uses: inside another job's steps.
Why A is wrong: Tempting since JavaScript actions run directly on the runner, but they require rewriting the logic as a Node entry point, which the team explicitly wants to avoid for plain shell steps.
Why B is wrong: Tempting because containers also run shell commands, but a Docker action needs an image build and only runs on Linux runners, which is heavier than the shell-only packaging requested.
Why C is correct: Composite actions are defined by using: composite plus a steps list, which is exactly the construct for wrapping a sequence of run steps into one publishable action referenced with uses.
Why D is wrong: Tempting as reusable workflows also promote reuse, but they are called at the job level with uses under jobs, not as a step action, so they cannot bundle individual run steps.