Table of Contents
- Action Metadata Overview
- Use Case: Caching & Installing Dependencies
- Sample Workflow Before Refactoring
- Defining the Composite Action
- Using Your Composite Action
- Links and References
Action Metadata Overview
Every custom GitHub Action requires a metadata file (action.yml or action.yaml). At minimum, include:
- name: Visual identifier
- description: Short summary
- inputs/outputs (optional): Dynamic parameters
- runs: Runtime configuration
| Runtime Type | Syntax Example |
|---|---|
| JavaScript | yaml<br>runs:<br> using: 'node20'<br> main: 'main.js'<br> |
| Docker | yaml<br>runs:<br> using: 'docker'<br> image: 'Dockerfile'<br> |
| Composite | yaml<br>runs:<br> using: 'composite'<br> steps:<br> # series of run or uses steps<br> |
Composite actions let you chain multiple
uses: and run: steps, apply if conditions, and even define pre/post scripts. They don’t require separate Docker or Node environments.Use Case: Caching & Installing Dependencies
Imagine a CI workflow with two jobs—Unit Testing and Code Coverage—both executing:- Checkout repository
- Set up Node.js
- Cache NPM dependencies
- Install dependencies
Sample Workflow Before Refactoring
cache and install steps. Let’s extract them next.
Defining the Composite Action
-
Create a directory for custom actions:
-
Populate
action.yml:
- Inputs
cache-folder: Makes the cache path configurable.
- Steps
- Reproduce the original cache and install commands.
Composite actions currently do not support Docker-level isolation. All steps run in the same default environment.
Using Your Composite Action
Update your workflow jobs to replace separate cache and install steps with oneuses: entry:
uses: step in Code Coverage or any other job. Now both jobs share a single, maintainable action.