{"meta":{"title":"Metadata syntax reference","intro":"You can create actions to perform tasks in your repository. If you're making a custom action, it will require a metadata file that uses YAML syntax.","product":"GitHub Actions","breadcrumbs":[{"href":"/en/enterprise-server@3.14/actions","title":"GitHub Actions"},{"href":"/en/enterprise-server@3.14/actions/reference","title":"Reference"},{"href":"/en/enterprise-server@3.14/actions/reference/workflows-and-actions","title":"Workflows and actions"},{"href":"/en/enterprise-server@3.14/actions/reference/workflows-and-actions/metadata-syntax","title":"Metadata syntax"}],"documentType":"article"},"body":"# Metadata syntax reference\n\nYou can create actions to perform tasks in your repository. If you're making a custom action, it will require a metadata file that uses YAML syntax.\n\n> \\[!NOTE]\n> You can build Docker container, JavaScript, and composite actions. Actions require a metadata file to define the inputs, outputs, and runs configuration for your action. Action metadata files use YAML syntax, and the metadata filename must be either `action.yml` or `action.yaml`. The preferred format is `action.yml`.\n\n## `name`\n\n**Required** The name of your action. GitHub displays the `name` in the **Actions** tab to help visually identify actions in each job.\n\n## `author`\n\n**Optional** The name of the action's author.\n\n## `description`\n\n**Required** A short description of the action.\n\n## `inputs`\n\n**Optional** Input parameters allow you to specify data that the action expects to use during runtime. GitHub stores input parameters as environment variables. We recommend using lowercase input ids.\n\n### Example: Specifying inputs\n\nThis example configures two inputs: `num-octocats` and `octocat-eye-color`. The `num-octocats` input is not required and will default to a value of `1`. `octocat-eye-color` is required and has no default value.\n\n> \\[!NOTE]\n> Actions using `required: true` will not automatically return an error if the input is not specified.\n\nWorkflow files that use this action can use the `with` keyword to set an input value for `octocat-eye-color`. For more information about the `with` syntax, see [Workflow syntax for GitHub Actions](/en/enterprise-server@3.14/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith).\n\n```yaml\ninputs:\n  num-octocats:\n    description: 'Number of Octocats'\n    required: false\n    default: '1'\n  octocat-eye-color:\n    description: 'Eye color of the Octocats'\n    required: true\n```\n\nWhen you specify an input, GitHub creates an environment variable for the input with the name `INPUT_<VARIABLE_NAME>`. The environment variable created converts input names to uppercase letters and replaces spaces with `_` characters.\n\nIf the action is written using a [composite](/en/enterprise-server@3.14/actions/creating-actions/creating-a-composite-action), then it will not automatically get `INPUT_<VARIABLE_NAME>`. With composite actions you can use `inputs` [Contexts reference](/en/enterprise-server@3.14/actions/learn-github-actions/contexts) to access action inputs.\n\nTo access the environment variable in a Docker container action, you must pass the input using the `args` keyword in the action metadata file. For more information about the action metadata file for Docker container actions, see [Creating a Docker container action](/en/enterprise-server@3.14/actions/creating-actions/creating-a-docker-container-action#creating-an-action-metadata-file).\n\nFor example, if a workflow defined the `num-octocats` and `octocat-eye-color` inputs, the action code could read the values of the inputs using the `INPUT_NUM-OCTOCATS` and `INPUT_OCTOCAT-EYE-COLOR` environment variables.\n\n### `inputs.<input_id>`\n\n**Required** A `string` identifier to associate with the input. The value of `<input_id>` is a map of the input's metadata. The `<input_id>` must be a unique identifier within the `inputs` object. The `<input_id>` must start with a letter or `_` and contain only alphanumeric characters, `-`, or `_`.\n\n### `inputs.<input_id>.description`\n\n**Required** A `string` description of the input parameter.\n\n### `inputs.<input_id>.required`\n\n**Optional** A `boolean` to indicate whether the action requires the input parameter. Set to `true` when the parameter is required.\n\n### `inputs.<input_id>.default`\n\n**Optional** A `string` representing the default value. The default value is used when an input parameter isn't specified in a workflow file.\n\n### `inputs.<input_id>.deprecationMessage`\n\n**Optional** If the input parameter is used, this `string` is logged as a warning message. You can use this warning to notify users that the input is deprecated and mention any alternatives.\n\n## `outputs` for Docker container and JavaScript actions\n\n**Optional** 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.\n\nOutputs can be a maximum of 1 MB per job. The total of all outputs in a workflow run can be a maximum of 50 MB. Size is approximated based on UTF-16 encoding.\n\nIf you don't declare an output in your action metadata file, you can still set outputs and use them in a workflow. For more information on setting outputs in an action, see [Workflow commands for GitHub Actions](/en/enterprise-server@3.14/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter).\n\n### Example: Declaring outputs for Docker container and JavaScript actions\n\n```yaml\noutputs:\n  sum: # id of the output\n    description: 'The sum of the inputs'\n```\n\n### `outputs.<output_id>`\n\n**Required** A `string` identifier to associate with the output. The value of `<output_id>` is a map of the output's metadata. The `<output_id>` must be a unique identifier within the `outputs` object. The `<output_id>` must start with a letter or `_` and contain only alphanumeric characters, `-`, or `_`.\n\n### `outputs.<output_id>.description`\n\n**Required** A `string` description of the output parameter.\n\n## `outputs` for composite actions\n\n**Optional** `outputs` use the same parameters as `outputs.<output_id>` and `outputs.<output_id>.description` (see [`outputs` for Docker container and JavaScript actions](#outputs-for-docker-container-and-javascript-actions)), but also includes the `value` token.\n\nOutputs can be a maximum of 1 MB per job. The total of all outputs in a workflow run can be a maximum of 50 MB. Size is approximated based on UTF-16 encoding.\n\n### Example: Declaring outputs for composite actions\n\n```yaml\noutputs:\n  random-number:\n    description: \"Random number\"\n    value: ${{ steps.random-number-generator.outputs.random-id }}\nruns:\n  using: \"composite\"\n  steps:\n    - id: random-number-generator\n      run: echo \"random-id=$(echo $RANDOM)\" >> $GITHUB_OUTPUT\n      shell: bash\n```\n\n### `outputs.<output_id>.value`\n\n**Required** The value that the output parameter will be mapped to. You can set this to a `string` or an expression with context. For example, you can use the `steps` context to set the `value` of an output to the output value of a step.\n\nFor more information on how to use context syntax, see [Contexts reference](/en/enterprise-server@3.14/actions/learn-github-actions/contexts).\n\n## `runs`\n\n**Required** Specifies whether this is a JavaScript action, a composite action, or a Docker container action and how the action is executed.\n\n## `runs` for JavaScript actions\n\n**Required** Configures the path to the action's code and the runtime used to execute the code.\n\n### Example: Using Node.js v24\n\n```yaml\nruns:\n  using: 'node24'\n  main: 'main.js'\n```\n\n### `runs.using` for JavaScript actions\n\n**Required** The runtime used to execute the code specified in [`main`](#runsmain).\n\n* Use `node20` for Node.js v20.\n* Use `node24` for Node.js v24.\n\n### `runs.main`\n\n**Required** The file that contains your action code. The runtime specified in [`using`](#runsusing-for-javascript-actions) executes this file.\n\n### `runs.pre`\n\n**Optional** 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 runtime specified with the [`using`](#runsusing-for-javascript-actions) syntax will execute this file. The `pre:` action always runs by default but you can override this using [`runs.pre-if`](#runspre-if).\n\n> \\[!NOTE]\n> `runs.pre` is not supported for local actions.\n\nIn this example, the `pre:` action runs a script called `setup.js`:\n\n```yaml\nruns:\n  using: 'node24'\n  pre: 'setup.js'\n  main: 'index.js'\n  post: 'cleanup.js'\n```\n\n### `runs.pre-if`\n\n**Optional** 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()`. In `pre-if`, status check functions evaluate against the job's status, not the action's own status.\n\nNote that the `step` context is unavailable, as no steps have run yet.\n\nIn this example, `cleanup.js` only runs on Linux-based runners:\n\n```yaml\n  pre: 'cleanup.js'\n  pre-if: runner.os == 'linux'\n```\n\n### `runs.post`\n\n**Optional** 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 runtime specified with the [`using`](#runsusing-for-javascript-actions) syntax will execute this file.\n\nIn this example, the `post:` action runs a script called `cleanup.js`:\n\n```yaml\nruns:\n  using: 'node24'\n  main: 'index.js'\n  post: 'cleanup.js'\n```\n\nThe `post:` action always runs by default but you can override this using `post-if`.\n\n### `runs.post-if`\n\n**Optional** 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()`. In `post-if`, status check functions evaluate against the job's status, not the action's own status.\n\nFor example, this `cleanup.js` will only run on Linux-based runners:\n\n```yaml\n  post: 'cleanup.js'\n  post-if: runner.os == 'linux'\n```\n\n## `runs` for composite actions\n\n**Required** Configures the path to the composite action.\n\n### `runs.using` for composite actions\n\n**Required** You must set this value to `'composite'`.\n\n### `runs.steps`\n\n**Required** The steps that you plan to run in this action. These can be either `run` steps or `uses` steps.\n\n#### `runs.steps[*].run`\n\n**Optional** The command you want to run. This can be inline or a script in your action repository:\n\n```yaml\nruns:\n  using: \"composite\"\n  steps:\n    - run: ${{ github.action_path }}/test/script.sh\n      shell: bash\n```\n\nAlternatively, you can use `$GITHUB_ACTION_PATH`:\n\n```yaml\nruns:\n  using: \"composite\"\n  steps:\n    - run: $GITHUB_ACTION_PATH/script.sh\n      shell: bash\n```\n\nFor more information, see [Contexts reference](/en/enterprise-server@3.14/actions/learn-github-actions/contexts#github-context).\n\n#### `runs.steps[*].shell`\n\n**Optional** The shell where you want to run the command. You can use any of the shells listed in [Workflow syntax for GitHub Actions](/en/enterprise-server@3.14/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell). Required if `run` is set.\n\n#### `runs.steps[*].if`\n\n**Optional** You can use the `if` conditional to prevent a step from running unless a condition is met. You can use any supported context and expression to create a conditional.\n\nWhen you use expressions in an `if` conditional, you can, optionally, omit the `${{ }}` expression syntax because GitHub Actions automatically evaluates the `if` conditional as an expression. However, this exception does not apply everywhere.\n\nYou must always use the `${{ }}` expression syntax or escape with `''`, `\"\"`, or `()` when the expression starts with `!`, since `!` is reserved notation in YAML format. For example:\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\nFor more information, see [Evaluate expressions in workflows and actions](/en/enterprise-server@3.14/actions/learn-github-actions/expressions).\n\n**Example: Using contexts**\n\nThis step only runs when the event type is a `pull_request` and the event action is `unassigned`.\n\n```yaml\nsteps:\n  - run: echo This event is a pull request that had an assignee removed.\n    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}\n```\n\n**Example: Using status check functions**\n\nThe `my backup step` only runs when the previous step of a composite action fails. For more information, see [Evaluate expressions in workflows and actions](/en/enterprise-server@3.14/actions/learn-github-actions/expressions#status-check-functions).\n\n```yaml\nsteps:\n  - name: My first step\n    uses: octo-org/action-name@main\n  - name: My backup step\n    if: ${{ failure() }}\n    uses: actions/heroku@1.0.0\n```\n\n#### `runs.steps[*].name`\n\n**Optional** The name of the composite step.\n\n#### `runs.steps[*].id`\n\n**Optional** A unique identifier for the step. You can use the `id` to reference the step in contexts. For more information, see [Contexts reference](/en/enterprise-server@3.14/actions/learn-github-actions/contexts).\n\n#### `runs.steps[*].env`\n\n**Optional** Sets a `map` of environment variables for only that step. If you want to modify the environment variable stored in the workflow, use `echo \"{name}={value}\" >> $GITHUB_ENV` in a composite step.\n\n#### `runs.steps[*].working-directory`\n\n**Optional** Specifies the working directory where the command is run.\n\n#### `runs.steps[*].uses`\n\n**Optional** Selects an action to run as part of a step in your job. An action is a reusable unit of code. You can use an action defined in the same repository as the workflow, a public repository, or in a [published Docker container image](https://hub.docker.com/).\n\nWe strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag number. If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.\n\n* Using the commit SHA of a released action version is the safest for stability and security.\n* Using the specific major action version allows you to receive critical fixes and security patches while still maintaining compatibility. It also assures that your workflow should still work.\n* Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.\n\nSome actions require inputs that you must set using the [`with`](/en/enterprise-server@3.14/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith) keyword. Review the action's README file to determine the inputs required.\n\n```yaml\nruns:\n  using: \"composite\"\n  steps:\n    # Reference a specific commit\n    - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3\n    # Reference the major version of a release\n    - uses: actions/checkout@v6\n    # Reference a specific version\n    - uses: actions/checkout@v6.2.0\n    # Reference a branch\n    - uses: actions/checkout@main\n    # References a subdirectory in a public GitHub repository at a specific branch, ref, or SHA\n    - uses: actions/aws/ec2@main\n    # References a local action\n    - uses: ./.github/actions/my-action\n    # References a docker public registry action\n    - uses: docker://gcr.io/cloud-builders/gradle\n    # Reference a docker image published on docker hub\n    - uses: docker://alpine:3.8\n```\n\n#### `runs.steps[*].with`\n\n**Optional** A `map` of the input parameters defined by the action. Each input parameter is a key/value pair. For more information, see [Example: Specifying inputs](#example-specifying-inputs).\n\n```yaml\nruns:\n  using: \"composite\"\n  steps:\n    - name: My first step\n      uses: actions/hello_world@main\n      with:\n        first_name: Mona\n        middle_name: The\n        last_name: Octocat\n```\n\n#### `runs.steps[*].continue-on-error`\n\n**Optional** Prevents the action from failing when a step fails. Set to `true` to allow the action to pass when this step fails.\n\n## `runs` for Docker container actions\n\n**Required** Configures the image used for the Docker container action.\n\n### Example: Using a Dockerfile in your repository\n\n```yaml\nruns:\n  using: 'docker'\n  image: 'Dockerfile'\n```\n\n### Example: Using public Docker registry container\n\n```yaml\nruns:\n  using: 'docker'\n  image: 'docker://debian:stretch-slim'\n```\n\n### `runs.using` for Docker container actions\n\n**Required** You must set this value to `'docker'`.\n\n### `runs.pre-entrypoint`\n\n**Optional** 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 [`runs.pre-if`](#runspre-if).\n\nThe runtime specified with the [`using`](#runsusing-for-docker-container-actions) syntax will execute this file.\n\nIn this example, the `pre-entrypoint:` action runs a script called `setup.sh`:\n\n```yaml\nruns:\n  using: 'docker'\n  image: 'Dockerfile'\n  args:\n    - 'bzz'\n  pre-entrypoint: 'setup.sh'\n  entrypoint: 'main.sh'\n```\n\n### `runs.image`\n\n**Required** 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, the file must be named `Dockerfile` and you must use a path relative to your action metadata file. The `docker` application will execute this file.\n\n### `runs.env`\n\n**Optional** Specifies a key/value map of environment variables to set in the container environment.\n\n### `runs.entrypoint`\n\n**Optional** 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 `ENTRYPOINT` documentation recommends using the *exec* form of the `ENTRYPOINT` instruction.\n\nFor more information about how the `entrypoint` executes, see [Dockerfile support for GitHub Actions](/en/enterprise-server@3.14/actions/creating-actions/dockerfile-support-for-github-actions#entrypoint).\n\n### `runs.post-entrypoint`\n\n**Optional** 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 [`runs.post-if`](#runspost-if).\n\n```yaml\nruns:\n  using: 'docker'\n  image: 'Dockerfile'\n  args:\n    - 'bzz'\n  entrypoint: 'main.sh'\n  post-entrypoint: 'cleanup.sh'\n```\n\n### `runs.args`\n\n**Optional** 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.\n\nThe `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:\n\n1. Document required arguments in the action's README and omit them from the `CMD` instruction.\n2. Use defaults that allow using the action without specifying any `args`.\n3. If the action exposes a `--help` flag, or something similar, use that to make your action self-documenting.\n\nIf you need to pass environment variables into an action, make sure your action runs a command shell to perform variable substitution. For example, if your `entrypoint` attribute is set to `\"sh -c\"`, `args` will be run in a command shell. Alternatively, if your `Dockerfile` uses an `ENTRYPOINT` to run the same command (`\"sh -c\"`), `args` will execute in a command shell.\n\nFor more information about using the `CMD` instruction with GitHub Actions, see [Dockerfile support for GitHub Actions](/en/enterprise-server@3.14/actions/creating-actions/dockerfile-support-for-github-actions#cmd).\n\n#### Example: Defining arguments for the Docker container\n\n```yaml\nruns:\n  using: 'docker'\n  image: 'Dockerfile'\n  args:\n    - ${{ inputs.greeting }}\n    - 'foo'\n    - 'bar'\n```\n\n## `branding`\n\n**Optional** You can use a color and [Feather](https://feathericons.com/) icon to create a badge to personalize and distinguish your action. Badges are shown next to your action name in [GitHub Marketplace](https://github.com/marketplace?type=actions).\n\n### Example: Configuring branding for an action\n\n```yaml\nbranding:\n  icon: 'award'\n  color: 'green'\n```\n\n### `branding.color`\n\nThe background color of the badge. Can be one of: `white`, `black`, `yellow`, `blue`, `green`, `orange`, `red`, `purple`, or `gray-dark`.\n\n### `branding.icon`\n\nThe name of the v4.28.0 [Feather](https://feathericons.com/) icon to use.\n\n#### Omitted icons\n\nBrand icons, and all the following icons, are omitted.\n\n<ul style=\"-webkit-column-count: 4; -moz-column-count: 4; column-count: 4;\">\n<li>coffee</li>\n<li>columns</li>\n<li>divide-circle</li>\n<li>divide-square</li>\n<li>divide</li>\n<li>frown</li>\n<li>hexagon</li>\n<li>key</li>\n<li>meh</li>\n<li>mouse-pointer</li>\n<li>smile</li>\n<li>tool</li>\n<li>x-octagon</li>\n</ul>\n\n#### Exhaustive list of all currently supported icons\n\n<!--\n  This list should match the icon list in `app/models/repository_actions/icons.rb` in the internal github repo.\n  To support a new icon, update `app/models/repository_actions/icons.rb` and add the svg to `/static/images/icons/feather` in the internal github repo.\n-->\n\n<ul style=\"-webkit-column-count: 4; -moz-column-count: 4; column-count: 4;\">\n<li>activity</li>\n<li>airplay</li>\n<li>alert-circle</li>\n<li>alert-octagon</li>\n<li>alert-triangle</li>\n<li>align-center</li>\n<li>align-justify</li>\n<li>align-left</li>\n<li>align-right</li>\n<li>anchor</li>\n<li>aperture</li>\n<li>archive</li>\n<li>arrow-down-circle</li>\n<li>arrow-down-left</li>\n<li>arrow-down-right</li>\n<li>arrow-down</li>\n<li>arrow-left-circle</li>\n<li>arrow-left</li>\n<li>arrow-right-circle</li>\n<li>arrow-right</li>\n<li>arrow-up-circle</li>\n<li>arrow-up-left</li>\n<li>arrow-up-right</li>\n<li>arrow-up</li>\n<li>at-sign</li>\n<li>award</li>\n<li>bar-chart-2</li>\n<li>bar-chart</li>\n<li>battery-charging</li>\n<li>battery</li>\n<li>bell-off</li>\n<li>bell</li>\n<li>bluetooth</li>\n<li>bold</li>\n<li>book-open</li>\n<li>book</li>\n<li>bookmark</li>\n<li>box</li>\n<li>briefcase</li>\n<li>calendar</li>\n<li>camera-off</li>\n<li>camera</li>\n<li>cast</li>\n<li>check-circle</li>\n<li>check-square</li>\n<li>check</li>\n<li>chevron-down</li>\n<li>chevron-left</li>\n<li>chevron-right</li>\n<li>chevron-up</li>\n<li>chevrons-down</li>\n<li>chevrons-left</li>\n<li>chevrons-right</li>\n<li>chevrons-up</li>\n<li>circle</li>\n<li>clipboard</li>\n<li>clock</li>\n<li>cloud-drizzle</li>\n<li>cloud-lightning</li>\n<li>cloud-off</li>\n<li>cloud-rain</li>\n<li>cloud-snow</li>\n<li>cloud</li>\n<li>code</li>\n<li>command</li>\n<li>compass</li>\n<li>copy</li>\n<li>corner-down-left</li>\n<li>corner-down-right</li>\n<li>corner-left-down</li>\n<li>corner-left-up</li>\n<li>corner-right-down</li>\n<li>corner-right-up</li>\n<li>corner-up-left</li>\n<li>corner-up-right</li>\n<li>cpu</li>\n<li>credit-card</li>\n<li>crop</li>\n<li>crosshair</li>\n<li>database</li>\n<li>delete</li>\n<li>disc</li>\n<li>dollar-sign</li>\n<li>download-cloud</li>\n<li>download</li>\n<li>droplet</li>\n<li>edit-2</li>\n<li>edit-3</li>\n<li>edit</li>\n<li>external-link</li>\n<li>eye-off</li>\n<li>eye</li>\n<li>fast-forward</li>\n<li>feather</li>\n<li>file-minus</li>\n<li>file-plus</li>\n<li>file-text</li>\n<li>file</li>\n<li>film</li>\n<li>filter</li>\n<li>flag</li>\n<li>folder-minus</li>\n<li>folder-plus</li>\n<li>folder</li>\n<li>gift</li>\n<li>git-branch</li>\n<li>git-commit</li>\n<li>git-merge</li>\n<li>git-pull-request</li>\n<li>globe</li>\n<li>grid</li>\n<li>hard-drive</li>\n<li>hash</li>\n<li>headphones</li>\n<li>heart</li>\n<li>help-circle</li>\n<li>home</li>\n<li>image</li>\n<li>inbox</li>\n<li>info</li>\n<li>italic</li>\n<li>layers</li>\n<li>layout</li>\n<li>life-buoy</li>\n<li>link-2</li>\n<li>link</li>\n<li>list</li>\n<li>loader</li>\n<li>lock</li>\n<li>log-in</li>\n<li>log-out</li>\n<li>mail</li>\n<li>map-pin</li>\n<li>map</li>\n<li>maximize-2</li>\n<li>maximize</li>\n<li>menu</li>\n<li>message-circle</li>\n<li>message-square</li>\n<li>mic-off</li>\n<li>mic</li>\n<li>minimize-2</li>\n<li>minimize</li>\n<li>minus-circle</li>\n<li>minus-square</li>\n<li>minus</li>\n<li>monitor</li>\n<li>moon</li>\n<li>more-horizontal</li>\n<li>more-vertical</li>\n<li>move</li>\n<li>music</li>\n<li>navigation-2</li>\n<li>navigation</li>\n<li>octagon</li>\n<li>package</li>\n<li>paperclip</li>\n<li>pause-circle</li>\n<li>pause</li>\n<li>percent</li>\n<li>phone-call</li>\n<li>phone-forwarded</li>\n<li>phone-incoming</li>\n<li>phone-missed</li>\n<li>phone-off</li>\n<li>phone-outgoing</li>\n<li>phone</li>\n<li>pie-chart</li>\n<li>play-circle</li>\n<li>play</li>\n<li>plus-circle</li>\n<li>plus-square</li>\n<li>plus</li>\n<li>pocket</li>\n<li>power</li>\n<li>printer</li>\n<li>radio</li>\n<li>refresh-ccw</li>\n<li>refresh-cw</li>\n<li>repeat</li>\n<li>rewind</li>\n<li>rotate-ccw</li>\n<li>rotate-cw</li>\n<li>rss</li>\n<li>save</li>\n<li>scissors</li>\n<li>search</li>\n<li>send</li>\n<li>server</li>\n<li>settings</li>\n<li>share-2</li>\n<li>share</li>\n<li>shield-off</li>\n<li>shield</li>\n<li>shopping-bag</li>\n<li>shopping-cart</li>\n<li>shuffle</li>\n<li>sidebar</li>\n<li>skip-back</li>\n<li>skip-forward</li>\n<li>slash</li>\n<li>sliders</li>\n<li>smartphone</li>\n<li>speaker</li>\n<li>square</li>\n<li>star</li>\n<li>stop-circle</li>\n<li>sun</li>\n<li>sunrise</li>\n<li>sunset</li>\n<li>table</li>\n<li>tablet</li>\n<li>tag</li>\n<li>target</li>\n<li>terminal</li>\n<li>thermometer</li>\n<li>thumbs-down</li>\n<li>thumbs-up</li>\n<li>toggle-left</li>\n<li>toggle-right</li>\n<li>trash-2</li>\n<li>trash</li>\n<li>trending-down</li>\n<li>trending-up</li>\n<li>triangle</li>\n<li>truck</li>\n<li>tv</li>\n<li>type</li>\n<li>umbrella</li>\n<li>underline</li>\n<li>unlock</li>\n<li>upload-cloud</li>\n<li>upload</li>\n<li>user-check</li>\n<li>user-minus</li>\n<li>user-plus</li>\n<li>user-x</li>\n<li>user</li>\n<li>users</li>\n<li>video-off</li>\n<li>video</li>\n<li>voicemail</li>\n<li>volume-1</li>\n<li>volume-2</li>\n<li>volume-x</li>\n<li>volume</li>\n<li>watch</li>\n<li>wifi-off</li>\n<li>wifi</li>\n<li>wind</li>\n<li>x-circle</li>\n<li>x-square</li>\n<li>x</li>\n<li>zap-off</li>\n<li>zap</li>\n<li>zoom-in</li>\n<li>zoom-out</li>\n</ul>"}