Using pre-written building blocks in your workflow

Overview

You can use pre-written building blocks, called actions, in your workflow. An action is a pre-defined, reusable set of jobs or code that perform specific tasks within a workflow.

Actions can be:

• Reusable: actions can be used across different workflows and repositories, allowing you to avoid rewriting the same code.
• Pre-written: many actions are available in the GitHub Marketplace, covering a wide range of tasks like checking out code, setting up environments, running tests, and deploying applications.
• Configurable: you can configure actions with inputs, outputs, and environment variables to tailor them to your specific needs.
• Community-driven: you can create your own actions and share them with others or use actions developed by the community.

The actions you use in your workflow can be defined in:

• The same repository as your workflow file
• An internal repository within the same enterprise account that is configured to allow access to workflows
• Any public repository
• A published Docker container image on Docker Hub

GitHub Marketplace is a central location for you to find actions created by the GitHub community.

Adding an action from the same repository

If an action is defined in the same repository where your workflow file uses the action, you can reference the action with either the ‌{owner}/{repo}@{ref} or ./path/to/dir syntax in your workflow file.

Exemplo de estrutura de arquivo de repositório:

|-- hello-world (repository)
|   |__ .github
|       └── workflows
|           └── my-first-workflow.yml
|       └── actions
|           |__ hello-world-action
|               └── action.yml

O caminho é relativo (./) ao diretório de trabalho padrão (github.workspace, $GITHUB_WORKSPACE). Se a ação fizer check-out do repositório para um local diferente do fluxo de trabalho, o caminho relativo usado para ações locais deverá ser atualizado.

Exemplo de arquivo de fluxo de trabalho:

jobs:
  my_first_job:
    runs-on: ubuntu-latest
    steps:
      # This step checks out a copy of your repository.
      - name: My first step - check out repository
        uses: actions/checkout@v4
      # This step references the directory that contains the action.
      - name: Use local hello-world-action
        uses: ./.github/actions/hello-world-action

The action.yml file is used to provide metadata for the action. Learn about the content of this file in "Sintaxe de metadados para o GitHub Actions."

Adding an action from a different repository

If an action is defined in a different repository than your workflow file, you can reference the action with the {owner}/{repo}@{ref} syntax in your workflow file.

The action must be stored in a public repository or an internal repository that is configured to allow access to workflows. For more information, see "Compartilhando ações e fluxos de trabalho com sua empresa."

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/setup-node@v4

Referencing a container on Docker Hub

If an action is defined in a published Docker container image on Docker Hub, you must reference the action with the docker://{image}:{tag} syntax in your workflow file. To protect your code and data, we strongly recommend you verify the integrity of the Docker container image from Docker Hub before using it in your workflow.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8

For some examples of Docker actions, see the Docker-image.yml workflow and "Criando uma ação de contêiner do Docker."

Security hardening for using actions in your workflows

O GitHub oferece recursos de segurança que você pode usar para aumentar a segurança de seus fluxos de trabalho. Você pode usar os recursos internos do GitHub para garantir que receba notificações sobre vulnerabilidades nas ações que consome ou para automatizar o processo de manter as ações em seus fluxos de trabalho atualizadas. Para obter mais informações, confira "Usar os recursos de segurança do GitHub para proteger seu uso do GitHub Actions".

Using release management for your custom actions

The creators of a community action have the option to use tags, branches, or SHA values to manage releases of the action. Similar to any dependency, you should indicate the version of the action you'd like to use based on your comfort with automatically accepting updates to the action.

You will designate the version of the action in your workflow file. Check the action's documentation for information on their approach to release management, and to see which tag, branch, or SHA value to use.

Using tags

Tags are useful for letting you decide when to switch between major and minor versions, but these are more ephemeral and can be moved or deleted by the maintainer. This example demonstrates how to target an action that's been tagged as v1.0.1:

steps:
  - uses: actions/javascript-action@v1.0.1

Using SHAs

If you need more reliable versioning, you should use the SHA value associated with the version of the action. SHAs are immutable and therefore more reliable than tags or branches. However, this approach means you will not automatically receive updates for an action, including important bug fixes and security updates. You must use a commit's full SHA value, and not an abbreviated value. Ao selecionar um SHA, verifique se ele está no repositório da ação e não em uma bifurcação do repositório. This example targets an action's SHA:

steps:
  - uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f

Using branches

Specifying a target branch for the action means it will always run the version currently on that branch. This approach can create problems if an update to the branch includes breaking changes. This example targets a branch named @main:

steps:
  - uses: actions/javascript-action@main

For more information, see "Sobre ações personalizadas."

Using inputs and outputs with an action

An action often accepts or requires inputs and generates outputs that you can use. For example, an action might require you to specify a path to a file, the name of a label, or other data it will use as part of the action processing.

To see the inputs and outputs of an action, check the action.yml or action.yaml in the root directory of the repository.

In this example action.yml, the inputs keyword defines a required input called file-path, and includes a default value that will be used if none is specified. The outputs keyword defines an output called results-file, which tells you where to locate the results.

name: "Example"
description: "Receives file and generates output"
inputs:
  file-path: # id of input
    description: "Path to test script"
    required: true
    default: "test-file.js"
outputs:
  results-file: # id of output
    description: "Path to results file"

Next steps

To continue learning about GitHub Actions, see "Entendendo o GitHub Actions."