LEARN. PRACTICE. GROW.Concept and mechanism
An action is an executable component with metadata in action.yml or action.yaml. Its runs configuration defines execution form; inputs and outputs form a consumer interface. In a composite action, reference inputs explicitly and map outputs to identified step results. Do not assume automatic INPUT_ creation for that action type. A JavaScript action needs its entrypoint and dependencies available in the distributed package; the current tutorial uses a bundle. A Docker container action requires Linux with Docker. Choosing among these forms should consider portability, dependencies, maintenance, and diagnostic-log clarity. A successful local build alone does not establish that consumers received a complete package.
Guided application
In a fictional platform team, prepare an action validating a release manifest and returning a digest. Document mandatory inputs and validate them rather than assuming metadata implements all validation. Rehearsals should include missing inputs, unexpected values, and consumers on older versions. A semantic change can be incompatible even when the input name stays unchanged. Publish identifiable versions and coordinate migration. Immutable releases protect their associated tag and assets; a moving major alias needs a separate lifecycle without an associated immutable release. Consumers pinned to a SHA need deliberate updates when an approved fix becomes available.
The release points to dist/index.js, but that file was not distributed: the package is incomplete.
Common pitfalls
Package.json as automatic installation; required as complete validation; stable name as compatibility; SHA as safety proof.
Related topics: Events, filters, and dependencies · Data, outputs, and service networking · Reuse, artifacts, and troubleshooting
Treat the action as versioned software that other teams need to operate.
Reference: Action metadata · GH-200 skills measured January2026;study guide updated2026-02-05