GitHub Action
YAML GitHub Actions
| Type | object |
|---|---|
| File match |
action.yml
action.yaml
|
| Schema URL | https://catalog.lintel.tools/schemas/schemastore/github-action/latest.json |
| Source | https://www.schemastore.org/github-action.json |
Validate with Lintel
npx @lintel/lintel checkProperties
The name of your action. GitHub displays the name in the Actions tab to help visually identify actions in each job.
A short description of the action.
The name of the action's author.
Input parameters allow you to specify data that the action expects to use during runtime. GitHub stores input parameters as environment variables. Input ids with uppercase letters are converted to lowercase during runtime. We recommended using lowercase input ids.
You can use a color and Feather icon to create a badge to personalize and distinguish your action. Badges are shown next to your action name in GitHub Marketplace.
2 nested properties
The background color of the badge.
The name of the Feather icon to use.
Definitions
Allows you to define conditions for the pre: action execution. The pre: action will only run if the conditions in pre-if are met. If not set, then pre-if defaults to always(). Note that the step context is unavailable, as no steps have run yet.
Allows you to define conditions for the post: action execution. The post: action will only run if the conditions in post-if are met. If not set, then post-if defaults to always().
Configures the path to the action's code and the application used to execute the code.
The application used to execute the code specified in main.
The file that contains your action code. The application specified in using executes this file.
Allows you to run a script at the start of a job, before the main: action begins. For example, you can use pre: to run a prerequisite setup script. The application specified with the using syntax will execute this file. The pre: action always runs by default but you can override this using pre-if.
Allows you to define conditions for the pre: action execution. The pre: action will only run if the conditions in pre-if are met. If not set, then pre-if defaults to always(). Note that the step context is unavailable, as no steps have run yet.
Allows you to run a script at the end of a job, once the main: action has completed. For example, you can use post: to terminate certain processes or remove unneeded files. The application specified with the using syntax will execute this file. The post: action always runs by default but you can override this using post-if.
Allows you to define conditions for the post: action execution. The post: action will only run if the conditions in post-if are met. If not set, then post-if defaults to always().
Configures the path to the composite action, and the application used to execute the code.
To use a composite run steps action, set this to 'composite'.
The run steps that you plan to run in this action.
Configures the image used for the Docker action.
You must set this value to 'docker'.
The Docker image to use as the container to run the action. The value can be the Docker base image name, a local Dockerfile in your repository, or a public image in Docker Hub or another registry. To reference a Dockerfile local to your repository, use a path relative to your action metadata file. The docker application will execute this file.
Specifies a key/value map of environment variables to set in the container environment.
Overrides the Docker ENTRYPOINT in the Dockerfile, or sets it if one wasn't already specified. Use entrypoint when the Dockerfile does not specify an ENTRYPOINT or you want to override the ENTRYPOINT instruction. If you omit entrypoint, the commands you specify in the Docker ENTRYPOINT instruction will execute. The Docker ENTRYPOINT instruction has a *shell* form and *exec* form. The Docker ENTRYPOINTdocumentation recommends using the *exec* form of theENTRYPOINT` instruction.
Allows you to run a script before the entrypoint action begins. For example, you can use pre-entrypoint: to run a prerequisite setup script. GitHub Actions uses docker run to launch this action, and runs the script inside a new container that uses the same base image. This means that the runtime state is different from the main entrypoint container, and any states you require must be accessed in either the workspace, HOME, or as a STATE_ variable. The pre-entrypoint: action always runs by default but you can override this using pre-if.
Allows you to define conditions for the pre: action execution. The pre: action will only run if the conditions in pre-if are met. If not set, then pre-if defaults to always(). Note that the step context is unavailable, as no steps have run yet.
Allows you to run a cleanup script once the runs.entrypoint action has completed. GitHub Actions uses docker run to launch this action. Because GitHub Actions runs the script inside a new container using the same base image, the runtime state is different from the main entrypoint container. You can access any state you need in either the workspace, HOME, or as a STATE_ variable. The post-entrypoint: action always runs by default but you can override this using post-if.
Allows you to define conditions for the post: action execution. The post: action will only run if the conditions in post-if are met. If not set, then post-if defaults to always().
An array of strings that define the inputs for a Docker container. Inputs can include hardcoded strings. GitHub passes the args to the container's ENTRYPOINT when the container starts up.
The args are used in place of the CMD instruction in a Dockerfile. If you use CMD in your Dockerfile, use the guidelines ordered by preference:
- Document required arguments in the action's README and omit them from the
CMDinstruction. - Use defaults that allow using the action without specifying any
args. - If the action exposes a
--helpflag, or something similar, use that to make your action self-documenting.
Output parameters allow you to declare data that an action sets. Actions that run later in a workflow can use the output data set in previously run actions. For example, if you had an action that performed the addition of two inputs (x + y = z), the action could output the sum (z) for other actions to use as an input. If you don't declare an output in your action metadata file, you can still set outputs and use them in a workflow.
Output parameters allow you to declare data that an action sets. Actions that run later in a workflow can use the output data set in previously run actions. For example, if you had an action that performed the addition of two inputs (x + y = z), the action could output the sum (z) for other actions to use as an input. If you don't declare an output in your action metadata file, you can still set outputs and use them in a workflow.