Skip to main content

Sintaxe de fluxo de trabalho para o GitHub Actions

Neste artigo

Um fluxo de trabalho é um processo automatizado configurável constituído de um ou mais trabalhos. Você deve criar um arquivo YAML para definir a configuração do seu fluxo de trabalho.

Sobre sintaxe YAML para fluxos de trabalho

Arquivos de fluxo de trabalho usam sintaxe YAML e devem ter uma extensão de arquivo .yml ou .yaml. Se você é novo no YAML e deseja aprender mais, consulte "Aprenda YAML em Y minutes".

Você deve armazenar os arquivos de fluxo de trabalho no diretório .github/workflows do seu repositório.

name

Nome do fluxo de trabalho. O GitHub exibe os nomes dos fluxos de trabalho na página de ações do repositório. Se você omitir o nome, o GitHub irá defini-lo como o caminho do arquivo do fluxo de trabalho relativo à raiz do repositório.

on

To automatically trigger a workflow, use on to define which events can cause the workflow to run. Para obter uma lista de eventos disponíveis, consulte "Eventos que acionam fluxos de trabalho".

You can define single or multiple events that can a trigger workflow, or set a time schedule. You can also restrict the execution of a workflow to only occur for specific files, tags, or branch changes. Estas opções são descritas nas seguintes seções.

Using a single event

For example, a workflow with the following on value will run when a push is made to any branch in the workflow's repository:

on: push

Using multiple events

You can specify a single event or multiple events. For example, a workflow with the following on value will run when a push is made to any branch in the repository or when someone forks the repository:

on: [push, fork]

If you specify multiple events, only one of those events needs to occur to trigger your workflow. If multiple triggering events for your workflow occur at the same time, multiple workflow runs will be triggered.

Using activity types

Some events have activity types that give you more control over when your workflow should run.

For example, the issue_comment event has the created, edited, and deleted activity types. If your workflow triggers on the label event, it will run whenever a label is created, edited, or deleted. If you specify the created activity type for the label event, your workflow will run when a label is created but not when a label is edited or deleted.

on:
  label:
    types:
      - created

If you specify multiple activity types, only one of those event activity types needs to occur to trigger your workflow. If multiple triggering event activity types for your workflow occur at the same time, multiple workflow runs will be triggered. For example, the following workflow triggers when an issue is opened or labeled. If an issue with two labels is opened, three workflow runs will start: one for the issue opened event and two for the two issue labeled events.

on:
  issue:
    types:
      - opened
      - labeled

Using filters

Some events have filters that give you more control over when your workflow should run.

For example, the push event has a branches filter that causes your workflow to run only when a push to a branch that matches the branches filter occurs, instead of when any push occurs.

on:
  push:
    branches:
      - main
      - 'releases/**'

Using activity types and filters with multiple events

If you specify activity types or filters for an event and your workflow triggers on multiple events, you must configure each event separately. Você deve anexar dois pontos (:) a todos os eventos, incluindo eventos sem configuração.

For example, a workflow with the following on value will run when:

  • A label is created
  • A push is made to the main branch in the repository
  • A push is made to a GitHub Pages-enabled branch
on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

on.<event_name>.types

Use on.<event_name>.types to define the type of activity that will trigger a workflow run. A maioria dos eventos GitHub são acionados por mais de um tipo de atividade. For example, the label is triggered when a label is created, edited, or deleted. A palavra-chave types (tipos) permite que você limite a atividade que faz com que o fluxo de trabalho seja executado. Quando somente um tipo de atividade aciona um evento de webhook, a palavra-chave types (tipos) é desnecessária.

É possível usar um array de types (tipos) de evento. Para obter mais informações sobre cada evento e seus tipos de atividades, consulte "Eventos que acionam fluxos de trabalho".

on:
  label:
    types: [created, edited]

on.<pull_request|pull_request_target>.<branches|branches-ignore>

When using the pull_request and pull_request_target events, you can configure a workflow to run only for pull requests that target specific branches.

Use the branches filter when you want to include branch name patterns or when you want to both include and exclude branch names patterns. Use the branches-ignore filter when you only want to exclude branch name patterns. You cannot use both the branches and branches-ignore filters for the same event in a workflow.

If you define both branches/branches-ignore and paths, the workflow will only run when both filters are satisfied.

The branches and branches-ignore keywords accept glob patterns that use characters like *, **, +, ?, ! and others to match more than one branch name. If a name contains any of these characters and you want a literal match, you need to escape each of these special characters with \. Para obter mais informações sobre padrões de glob, consulte a "Folha de informações para filtrar padrões".

Example: Including branches

The patterns defined in branches are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a pull_request event for a pull request targeting:

  • A branch named main (refs/heads/main)
  • A branch named mona/octocat (refs/heads/mona/octocat)
  • A branch whose name starts with releases/, like releases/10 (refs/heads/releases/10)
on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:    
      - main
      - 'mona/octocat'
      - 'releases/**'

Example: Excluding branches

When a pattern matches the branches-ignore pattern, the workflow will not run. The patterns defined in branches are evaluated against the Git ref's name. For example, the following workflow would run whenever there is a pull_request event unless the pull request is targeting:

  • A branch named mona/octocat (refs/heads/mona/octocat)
  • A branch whose name matches releases/**-alpha, like beta/3-alpha (refs/releases/beta/3-alpha)
on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:    
      - 'mona/octocat'
      - 'releases/**-alpha'

Example: Including and excluding branches

You cannot use branches and branches-ignore to filter the same event in a single workflow. If you want to both include and exclude branch patterns for a single event, use the branches filter along with the ! character to indicate which branches should be excluded.

If you define a branch with the ! character, you must also define at least one branch without the ! character. If you only want to exclude branches, use branches-ignore instead.

A ordem de definição dos padrões é importante.

  • Um padrão negativo (precedido por !) depois de uma correspondência positiva excluirá o Git ref.
  • Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.

The following workflow will run on pull_request events for pull requests that target releases/10 or releases/beta/mona, but for pull requests that target releases/10-alpha or releases/beta/3-alpha because the negative pattern !releases/**-alpha follows the positive pattern.

on:
  pull_request:
    branches:    
      - 'releases/**'
      - '!releases/**-alpha'

on.push.<branches|tags|branches-ignore|tags-ignore>

When using the push event, you can configure a workflow to run on specific branches or tags.

Use the branches filter when you want to include branch name patterns or when you want to both include and exclude branch names patterns. Use the branches-ignore filter when you only want to exclude branch name patterns. You cannot use both the branches and branches-ignore filters for the same event in a workflow.

Use the tags filter when you want to include tag name patterns or when you want to both include and exclude tag names patterns. Use the tags-ignore filter when you only want to exclude tag name patterns. You cannot use both the tags and tags-ignore filters for the same event in a workflow.

If you define only tags/tag-ignore or only branches/branches-ignore, the workflow won't run for events affecting the undefined Git ref. If you define neither tags/tag-ignore or branches/branches-ignore, the workflow will run for events affecting either branches or tags. If you define both branches/branches-ignore and paths, the workflow will only run when both filters are satisfied.

As palavras-chave branches, branches-ignore, tags, and tags-ignore aceitam padrões do glob que usam caracteres como *, **, +, ?, ! e outros para corresponder a mais de um nome do branch ou tag. Se um nome contiver qualquer um desses caracteres e você quiser uma correspondência literal, você deverá escapar de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões de glob, consulte a "Folha de informações para filtrar padrões".

Exemplo: Incluindo branches e tags

Os padrões definidos nos branches e tags são avaliados relativamente ao nome do Git ref. For example, the following workflow would run whenever there is a push event to:

  • A branch named main (refs/heads/main)
  • A branch named mona/octocat (refs/heads/mona/octocat)
  • A branch whose name starts with releases/, like releases/10 (refs/heads/releases/10)
  • A tag named v2 (refs/tags/v2)
  • A tag whose name starts with v1., like v1.9.1 (refs/tags/v1.9.1)
on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:    
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:        
      - v2
      - v1.*

Example: Excluding branches and tags

When a pattern matches the branches-ignore or tags-ignore pattern, the workflow will not run. Os padrões definidos nos branches e tags são avaliados relativamente ao nome do Git ref. For example, the following workflow would run whenever there is a push event, unless the push event is to:

  • A branch named mona/octocat (refs/heads/mona/octocat)
  • A branch whose name matches releases/**-alpha, like beta/3-alpha (refs/releases/beta/3-alpha)
  • A tag named v2 (refs/tags/v2)
  • A tag whose name starts with v1., like v1.9 (refs/tags/v1.9)
on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:    
      - 'mona/octocat'
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:        
      - v2
      - v1.*

Example: Including and excluding branches and tags

You can't use branches and branches-ignore to filter the same event in a single workflow. Similarly, you can't use tags and tags-ignore to filter the same event in a single workflow. If you want to both include and exclude branch or tag patterns for a single event, use the branches or tags filter along with the ! character to indicate which branches or tags should be excluded.

If you define a branch with the ! character, you must also define at least one branch without the ! character. If you only want to exclude branches, use branches-ignore instead. Similarly, if you define a tag with the ! character, you must also define at least one tag without the ! character. If you only want to exclude tags, use tags-ignore instead.

A ordem de definição dos padrões é importante.

  • Um padrão negativo (precedido por !) depois de uma correspondência positiva excluirá o Git ref.
  • Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.

O fluxo de trabalho a seguir será executado em pushes para releases/10 ou releases/beta/mona, mas não em releases/10-alpha ou releases/beta/3-alpha, pois o padrão negativo !releases/**-alpha está na sequência do padrão positivo.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

on.<push|pull_request|pull_request_target>.<paths|paths-ignore>

When using the push and pull_request events, you can configure a workflow to run based on what file paths are changed. Path filters are not evaluated for pushes of tags.

Use the paths filter when you want to include file path patterns or when you want to both include and exclude file path patterns. Use the paths-ignore filter when you only want to exclude file path patterns. You cannot use both the paths and paths-ignore filters for the same event in a workflow.

If you define both branches/branches-ignore and paths, the workflow will only run when both filters are satisfied.

The paths and paths-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. Para obter mais informações, consulte a "Folha de consulta de filtro padrão".

Exemplo: Incluindo caminhos

Se pelo menos um caminho corresponder a um padrão no filtro paths, o fluxo de trabalho será executado. For example, the following workflow would run anytime you push a JavaScript file (.js).

on:
  push:
    paths:
      - '**.js'

Example: Excluding paths

Quando todos os caminhos de nome correspondem a padrões em paths-ignore, o fluxo de trabalho não será executado. If any path names do not match patterns in paths-ignore, even if some path names match the patterns, the workflow will run.

Um fluxo de trabalho com o seguinte filtro de caminho só será executado em eventos push que tiverem pelo menos um arquivo fora do diretório docs na raiz do repositório.

on:
  push:
    paths-ignore:
      - 'docs/**'

Example: Including and excluding paths

You can not use paths and paths-ignore to filter the same event in a single workflow. If you want to both include and exclude path patterns for a single event, use the paths filter along with the ! character to indicate which paths should be excluded.

If you define a path with the ! character, you must also define at least one path without the ! character. If you only want to exclude paths, use paths-ignore instead.

A ordem de definição dos padrões é importante:

  • Um padrão negativo (precedido por !) depois de uma correspondência positiva excluirá o caminho.
  • Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.

Este exemplo é executado sempre que o evento push inclui um arquivo no diretório sub-project ou seus subdiretórios, a menos que o arquivo esteja no diretório sub-project/docs. Por exemplo, um push que alterou sub-project/index.js ou sub-project/src/index.js acionará uma execução de fluxo de trabalho, mas um push que altere somentesub-project/docs/readme.md não acionará.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Comparações Git diff

Observação: Se você fizer push de mais de 1.000 commits, ou se GitHub não gerar o diff devido a um tempo limite, o fluxo de trabalho sempre será executado.

O filtro determina se um fluxo de trabalho deve ser executado avaliando os arquivos alterados e comparando-os à lista de paths-ignore ou paths. Se não houver arquivos alterados, o fluxo de trabalho não será executado.

O GitHub gera a lista de arquivos alterados usando diffs de dois pontos para pushes e diffs de três pontos para pull requests:

  • Pull requests: diffs de três pontos são uma comparação entre a versão mais recente do branch de tópico e o commit onde o branch de tópico foi sincronizado pela última vez com o branch de base.
  • Pushes para branches existentes: um diff de dois pontos compara os SHAs head e base, um com o outro.
  • Pushes para novos branches: um diff de dois pontos compara o principal do ancestral do commit mais extenso que foi feito push.

Os diffs limitam-se a 300 arquivos. Se houver arquivos alterados que não correspondam aos primeiros 300 arquivos retornados pelo filtro, o fluxo de trabalho não será executado. Talvez seja necessário criar filtros mais específicos para que o fluxo de trabalho seja executado automaticamente.

Para obter mais informações, consulte "Sobre comparação de branches em pull requests".

on.schedule

You can use on.schedule to define a time schedule for your workflows. É possível programar um fluxo de trabalho para ser executado em horários de UTC específicos usando a sintaxe de cron POSIX. Fluxos de trabalho agendados executados no último commit no branch padrão ou branch de base. O intervalo mais curto que você pode executar fluxos de trabalho agendados é a cada 15 minutos.

Este exemplo aciona o fluxo de trabalho todos os dias às 17:30 e 17:30 UTC:

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

A single workflow can be triggered by multiple schedule events. You can access the schedule event that triggered the workflow through the github.event.schedule context. This example triggers the workflow to run at 5:30 UTC every Monday-Thursday, but skips the Not on Monday or Wednesday step on Monday and Wednesday.

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 2,4'

jobs:
  test_schedule:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Monday or Wednesday
        if: github.event.schedule != '30 5 * * 1,3'
        run: echo "This step will be skipped on Monday and Wednesday"
      - name: Every time
        run: echo "This step will always run"

Para obter mais informações sobre a sintaxe cron, consulte "Eventos que acionam fluxos de trabalho".

on.workflow_call

Use on.workflow_call para definir as entradas e saídas para um fluxo de trabalho reutilizável. Você também pode mapear os segredos disponíveis para o fluxo de trabalho chamado. Para obter mais informações sobre fluxos de trabalho reutilizáveis, consulte "Reutilizando fluxos de trabalho".

on.workflow_call.inputs

Ao usar a palavra-chave workflow_call, você poderá, opcionalmente, especificar entradas que são passadas para o fluxo de trabalho chamado no fluxo de trabalho de chamada. Para obter mais informações sobre a palavra-chave workflow_call, consulte "Eventos que acionam fluxos de trabalho."

Além dos parâmetros de entrada padrão que estão disponíveis, on.workflow_call.inputs exige um parâmetro tipo. Para obter mais informações, consulte on.workflow_call.inputs.<input_id>.type.

Se um parâmetro padrão não fordefinido, o valor padrão da entrada será falso para um booleano, 0 para um número e "" para uma string.

No fluxo de trabalho chamado, você pode usar o contexto entradas para referir-se a uma entrada.

Se um fluxo de trabalho de chamada passar uma entrada que não é especificada no fluxo de trabalho de chamada, isso irá gerar um erro.

Exemplo

on:
  workflow_call:
    inputs:
      username:
        description: 'A username passed from the caller workflow'
        default: 'john-doe'
        required: false
        type: string

jobs:
  print-username:
    runs-on: ubuntu-latest

    steps:
      - name: Print the input name to STDOUT
        run: echo The username is ${{ inputs.username }}

Para obter mais informações, consulte "Reutilizando fluxos de trabalho".

on.workflow_call.inputs.<input_id>.type

Necessário se a entrada for definida para a palavra-chave on.workflow_call. O valor deste parâmetro é uma string que especifica o tipo de dados da entrada. Este deve ser um dos valores a seguir: booleano, número ou string.

on.workflow_call.outputs

Um mapa de saídas para um fluxo de trabalho chamado. As saídas de fluxo de trabalho chamadas estão disponíveis para todas as tarefas a jusante no fluxo de trabalho de chamadas. Cada saída tem um identificador, uma descrição opcional e um valor. O valor deve ser definido para o valor de uma saída de um trabalho dentro do fluxo de trabalho chamado.

No exemplo abaixo, dois valores de saída são definidos para este fluxo de trabalho reutilizável: workflow_output1 e workflow_output2. Eles são mapeados com as saídas chamadas job_output1 e job_output2, ambas de um trabalho chamado my_job.

Exemplo

on:
  workflow_call:
    # Map the workflow outputs to job outputs
    outputs:
      workflow_output1:
        description: "The first job output"
        value: ${{ jobs.my_job.outputs.job_output1 }}
      workflow_output2:
        description: "The second job output"
        value: ${{ jobs.my_job.outputs.job_output2 }}

Para obter informações sobre como fazer referência a uma saída de trabalho, consulte trabalhos.<job_id>.outputs. Para obter mais informações, consulte "Reutilizando fluxos de trabalho".

on.workflow_call.secrets

Um mapa dos segredos que pode ser usado no fluxo de trabalho de chamada.

Dentro do fluxo de trabalho de chamada, você pode usar o contexto segredos para consultar um segredo.

Se um fluxo de trabalho de chamada passar um segredo que não é especificado no fluxo de trabalho chamado, isso irá gerar um erro.

Exemplo

on:
  workflow_call:
    secrets:
      access-token:
        description: 'A token passed from the caller workflow'
        required: false

jobs:
  pass-secret-to-action:
    runs-on: ubuntu-latest

    steps:
      - name: Pass the received secret to an action
        uses: ./.github/actions/my-action@v1
        with:
          token: ${{ secrets.access-token }}

on.workflow_call.secrets.<secret_id>

Um identificador de string para associar ao segredo.

on.workflow_call.secrets.<secret_id>.required

Um booleano que especifica se o segredo deve ser fornecido.

on.workflow_run.<branches|branches-ignore>

When using the workflow_run event, you can specify what branches the triggering workflow must run on in order to trigger your workflow.

The branches and branches-ignore filters accept glob patterns that use characters like *, **, +, ?, ! and others to match more than one branch name. Se um nome contiver qualquer um desses caracteres e você quiser uma correspondência literal, você deverá escapar de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões de glob, consulte a "Folha de informações para filtrar padrões".

For example, a workflow with the following trigger will only run when the workflow named Build runs on a branch whose name starts with releases/:

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

A workflow with the following trigger will only run when the workflow named Build runs on a branch that is not named canary:

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

You cannot use both the branches and branches-ignore filters for the same event in a workflow. If you want to both include and exclude branch patterns for a single event, use the branches filter along with the ! character to indicate which branches should be excluded.

A ordem de definição dos padrões é importante.

  • A matching negative pattern (prefixed with !) after a positive match will exclude the branch.
  • A matching positive pattern after a negative match will include the branch again.

For example, a workflow with the following trigger will run when the workflow named Build runs on a branch that is named releases/10 or releases/beta/mona but will not releases/10-alpha, releases/beta/3-alpha, or main.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

on.workflow_dispatch.inputs

Ao usar o evento workflow_dispatch, você pode, opcionalmente, especificar as entradas que são passadas para o fluxo de trabalho.

O fluxo de trabalho acionado recebe as entradas no contexto github.event.inputs. Para obter mais informações, consulte "Contextos".

Exemplo

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning' 
        type: choice
        options:
        - info
        - warning
        - debug 
      tags:
        description: 'Test scenario tags'
        required: false 
        type: boolean
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true 

jobs:
  print-tag:
    runs-on: ubuntu-latest

    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tag is ${{ github.event.inputs.tag }} 

permissões

You can use permissions to modify the default permissions granted to the GITHUB_TOKEN, adding or removing access as required, so that you only allow the minimum required access. Para obter mais informações, consulte "Autenticação em um fluxo de trabalho".

Você pode usar as permissões de `como uma chave de nível superior, para aplicar a todos os trabalhos do fluxo de trabalho ou em trabalhos específicos. Ao adicionar a chave daspermissõesem um trabalho específico, todas as ações e comandos de execução dentro desse trabalho que usam oGITHUB_TOKEN ganham os direitos de acesso que você especificar. Para obter mais informações, consulte [jobs.<job_id>.permissions`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions).

Valores de acesso e escopos disponíveis:

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  id-token: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Se você especificar o acesso para qualquer um desses escopos, todos os que não são especificados são definidos como nenhum.

Você pode usar a sintaxe a seguir para definir o acesso de leitura ou gravação para todos os escopos disponíveis:

permissions: read-all|write-all

Você pode usar a chave de permissões para adicionar e remover permissões de leitura para repositórios bifurcados, mas, normalmente, você não pode conceder acesso de gravação. A exceção para esse comportamento é quando um usuário administrador selecionou a opção Enviar tokens para fluxos de trabalho de pull requests nas configurações do GitHub Actions. For more information, see "Managing GitHub Actions settings for a repository."

Example: Assigning permissions to GITHUB_TOKEN

Este exemplo mostra as permissões que estão sendo definidas para o GITHUB_TOKEN que será aplicado a todos os trabalhos do fluxo de trabalho. É concedido acesso de leitura a todas as permissões.

name: "My workflow"

on: [ push ]

permissions: read-all

jobs:
  ...

env

Um mapa das variáveis de ambiente que estão disponíveis para as etapas de todos os trabalhos do fluxo de trabalho. Também é possível definir variáveis de ambiente que estão disponíveis apenas para as etapas de um único trabalho ou para uma única etapa. Para obter mais informações, consulte jobs.<job_id>.env e jobs.<job_id>.steps[*].env.

Quando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável de ambiente mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá variáveis de trabalho e de fluxo de trabalho pelo mesmo nome enquanto a etapa é executada. Uma variável definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome, enquanto o trabalho é executado.

Exemplo

env:
  SERVER: production

padrões

Use defaults to create a map of default settings that will apply to all jobs in the workflow. Você também pode definir as configurações-padrão disponíveis para um trabalho. Para obter mais informações, consulte jobs.<job_id>.defaults.

Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.

defaults.run

You can use defaults.run to provide default shell and working-directory options for all run steps in a workflow. Você também pode definir as configurações-padrão para execução apenas disponíveis para um trabalho. Para obter mais informações, consulte jobs.<job_id>.defaults.run. Você não pode usar contextos ou expressões nesta palavra-chave.

Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.

Example: Set the default shell and working directory

defaults:
  run:
    shell: bash
    working-directory: scripts

concorrência

Use concurrency to ensure that only a single job or workflow using the same concurrency group will run at a time. Um grupo de concorrência pode ser qualquer string ou expressão. A expressão só pode usar o contexto github. Para obter mais informações sobre expressões, consulte "Expressões".

Você também pode especificar concorrência no nível do trabalho. Para obter mais informações, consulte jobs.<job_id>.concurrency.

Quando um trabalho simultâneo ou fluxo de trabalho é enfileirado, se outro trbalho ou fluxo de trabalho que usa o mesmo grupo de concorrência no repositório estiver em andamento o trabalho na fila ou o fluxo de trabalho ficará pendente. Qualquer trabalho ou fluxo de trabalho anterior pendente no grupo de concorrência será cancelado. Para cancelar também qualquer trabalho atualmente em execução ou fluxo de trabalho no mesmo grupo de concorrência, especifique cancel-in-progress: true.

Exemplos: Como usar a concorrência e o comportamento padrão

concurrency: staging_environment
concurrency: ci-${{ github.ref }}

Exemplo: Usar a concorrência para cancelar qualquer trabalho em andamento ou em execução

concurrency: 
  group: ${{ github.ref }}
  cancel-in-progress: true

Example: Using a fallback value

If you build the group name with a property that is only defined for specific events, you can use a fallback value. For example, github.head_ref is only defined on pull_request events. If your workflow responds to other events in addition to pull_request events, you will need to provide a fallback to avoid a syntax error. The following concurrency group cancels in-progress jobs or runs on pull_request events only; if github.head_ref is undefined, the concurrency group will fallback to the run ID, which is guaranteed to be both unique and defined for the run.

concurrency: 
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

Example: Only cancel in-progress jobs or runs for the current workflow

If you have multiple workflows in the same repository, concurrency group names must be unique across workflows to avoid canceling in-progress jobs or runs from other workflows. Otherwise, any previously in-progress or pending job will be canceled, regardless of the workflow.

To only cancel in-progress runs of the same workflow, you can use the github.workflow property to build the concurrency group:

concurrency: 
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs

A workflow run is made up of one or more jobs, which run in parallel by default. Para executar trabalhos sequencialmente, você pode definir dependências em outros trabalhos usando a palavra-chave jobs.<job_id>.needs.

Cada trabalho é executado em um ambiente de executor especificado por runs-on.

Você pode executar quantos trabalhos desejar, desde que esteja dentro dos limites de uso do fluxo de trabalho. Para obter mais informações, consulte "Limites de uso e cobrança" para executores hospedados em GitHub e "Sobre executores auto-hospedados" para limites de uso de executor auto-hospedado.

Se precisar encontrar o identificador exclusivo de uma tarefa em execução em um fluxo de trabalho, você poderá usar a API de GitHub. Para obter mais informações, consulte "Trabalhos do fluxo de trabalho".

jobs.<job_id>

Use jobs.<job_id> to give your job a unique identifier. A chave job_id é uma string, e seu valor é um mapa dos dados de configuração do trabalho. Você deve substituir <job_id> por uma string exclusiva para o objeto jobs. <job_id> deve começar por uma letra ou _, além de conter somente caracteres alfanuméricos, - ou _.

Example: Creating jobs

Neste exemplo, foram criados dois trabalhos e seus valores de job_id são my_first_job e my_second_job.

jobs:
  meu_primeiro_trabalho:
    name: meu primeiro trabalho
  meu_segundo_trabalho:
    name: meu segundo trabalho

jobs.<job_id>.name

Use jobs.<job_id>.name to a name for the job, which is displayed on GitHub.

jobs.<job_id>.permissions

For a specific job, you can use jobs.<job_id>.permissions to modify the default permissions granted to the GITHUB_TOKEN, adding or removing access as required, so that you only allow the minimum required access. Para obter mais informações, consulte "Autenticação em um fluxo de trabalho".

Ao especificar a permissão de uma definição de trabalho, você pode configurar um conjunto diferente de permissões para o GITHUB_TOKEN para cada trabalho, se necessário. Como alternativa, você pode especificar as permissões para todas as tarefas do fluxo de trabalho. Para informações sobre como definir permissões no nível do fluxo de trabalho, consulte permissões.

Valores de acesso e escopos disponíveis:

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  id-token: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

Se você especificar o acesso para qualquer um desses escopos, todos os que não são especificados são definidos como nenhum.

Você pode usar a sintaxe a seguir para definir o acesso de leitura ou gravação para todos os escopos disponíveis:

permissions: read-all|write-all

Você pode usar a chave de permissões para adicionar e remover permissões de leitura para repositórios bifurcados, mas, normalmente, você não pode conceder acesso de gravação. A exceção para esse comportamento é quando um usuário administrador selecionou a opção Enviar tokens para fluxos de trabalho de pull requests nas configurações do GitHub Actions. For more information, see "Managing GitHub Actions settings for a repository."

Example: Setting permissions for a specific job

Este exemplo mostra as permissões que estão sendo definidas para o GITHUB_TOKEN que só se aplicará ao trabalho denominado stale. O acesso de gravação é concedido para os escopos dos problemas e pull-requests. Todos os outros escopos não terão acesso.

jobs:
  stale:
    runs-on: ubuntu-latest

    permissions:
      issues: write
      pull-requests: write

    steps:
      - uses: actions/stale@v3

jobs.<job_id>.needs

Use jobs.<job_id>.needs to identify any jobs that must complete successfully before this job will run. Esse código pode ser uma string ou array de strings. Se houver falha em um trabalho, todos os trabalhos que dependem dele serão ignorados, a menos que os trabalhos usem uma expressão condicional que faça o trabalho continuar.

Example: Requiring successful dependent jobs

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

Neste exemplo, job1 deve ser concluído com êxito antes do início de job2, e job3 aguarda a conclusão de job1 e job2.

Os trabalhos neste exemplo são executados sequencialmente:

  1. job1
  2. job2
  3. job3

Example: Not requiring successful dependent jobs

jobs:
  job1:
  job2:
    needs: job1
  job3:
    if: ${{ always() }}
    needs: [job1, job2]

Neste exemplo, job3 usa a expressão condicional always() para que ela sempre seja executada depois de job1 e job2 terem sido concluídos, independentemente de terem sido bem sucedidos. Para obter mais informações, consulte "Expressões".

jobs.<job_id>.if

You can use the jobs.<job_id>.if conditional to prevent a job from running unless a condition is met. Você pode usar qualquer contexto e expressão compatível para criar uma condicional.

Quando você usa expressões em uma condicional if você pode omitir a sintaxe da expressão (${{ }}) porque GitHub calcula automaticamente a condição if como expressão. Para obter mais informações, consulte "Expressões".

Example: Only run job for specific repository

This example uses if to control when the production-deploy job can run. It will only run if the repository is named octo-repo-prod and is within the octo-org organization. Otherwise, the job will be marked as skipped.

YAML
name: example-workflow
on: [push]
jobs:
  production-deploy:
    if: github.repository == 'octo-org/octo-repo-prod'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install -g bats

jobs.<job_id>.runs-on

Use jobs.<job_id>.runs-on to define the type of machine to run the job on. A máquina pode ser ou um executor hospedado em GitHub ou um executor auto-hospedado. Você pode fornecer runs-on como uma única string ou como uma matriz de strings. Se você especificar uma matriz de strings, o seu fluxo de trabalho será executado em um executor auto-hospedado cujas etiquetas correspondam a todos os valores de runs-on, se disponível. Se você quiser executar seu fluxo de trabalho em várias máquinas, use jobs.<job_id>.strategy.

Choosing GitHub-hosted runners

Se você usar um executor hospedado no GitHub, cada trabalho será executado em uma nova instância de um ambiente virtual especificado por runs-on.

Os tipos de executor disponíveis para GitHub são:

Ambiente virtual Etiqueta de fluxo de trabalho YAML Observações
Windows Server 2022 windows-2022 The windows-latest label currently uses the Windows Server 2019 runner image.
Windows Server 2019 windows-latest ou windows-2019
Windows Server 2016[deprecated] windows-2016 Migrate to Windows 2019 or Windows 2022. For more information, see the blog post.
Ubuntu 20.04 ubuntu-latest ou ubuntu-20.04
Ubuntu 18.04 ubuntu-18.04
macOS Big Sur 11 macos-11 The macos-latest label currently uses the macOS 10.15 runner image.
macOS Catalina 10.15 macos-latest or macos-10.15

Note: Beta and Deprecated Images are provided "as-is", "with all faults" and "as available" and are excluded from the service level agreement and warranty. Beta Images may not be covered by customer support.

Example: Specifying an operating system

runs-on: ubuntu-latest

Para obter mais informações, consulte "Ambientes virtuais para executores hospedados em GitHub".

Choosing self-hosted runners

Para especificar um executor auto-hospedado para o seu trabalho, configure runs-on no seu arquivo de fluxo de trabalho com etiquetas de executores auto-hospedados.

All self-hosted runners have the self-hosted label. Using only this label will select any self-hosted runner. To select runners that meet certain criteria, such as operating system or architecture, we recommend providing an array of labels that begins with self-hosted (this must be listed first) and then includes additional labels as needed. When you specify an array of labels, jobs will be queued on runners that have all the labels that you specify.

Although the self-hosted label is not required, we strongly recommend specifying it when using self-hosted runners to ensure that your job does not unintentionally specify any current or future GitHub-hosted runners.

Example: Using labels for runner selection

runs-on: [self-hosted, linux]

Para obter mais informações, consulte "Sobre executores auto-hospedados" e "Usar executores auto-hospedados em um fluxo de trabalho."

jobs.<job_id>.environment

Use jobs.<job_id>.environment to define the environment that the job references. Todas as regras de proteção do ambiente têm de ser aprovadas para que um trabalho que faça referência ao ambiente seja enviado a um executor. Para obter mais informações, consulte "Usando ambientes para implantação".

Você pode fornecer o ambiente apenas como o nome do ambiente, ou como um objeto de ambiente com o nome e url. A URL é mapeada com environment_url na API de implantações. Para obter mais informações sobre a API de implantações, consulte "Implantações".

Example: Using a single environment name

ambiente: staging_environment

Example: Using environment name and URL

environment:
  name: production_environment
  url: https://github.com

A URL pode ser uma expressão e pode usar qualquer contexto, exceto para o contexto segredos. Para obter mais informações sobre expressões, consulte "Expressões".

Example: Using output as URL

environment:
  name: production_environment
  url: ${{ steps.step_id.outputs.url_output }}

jobs.<job_id>.concurrency

Observação: Quando a concorrência é especificada no nível do trabalho, não se garante a ordem para trabalhos ou execuções que são enfileiradas em 5 minutos uma da outra.

You can use jobs.<job_id>.concurrency to ensure that only a single job or workflow using the same concurrency group will run at a time. Um grupo de concorrência pode ser qualquer string ou expressão. A expressão pode usar qualquer contexto, exceto para o contexto de segredos. Para obter mais informações sobre expressões, consulte "Expressões".

Você também pode especificar concorrência no nível do fluxo de trabalho. Para obter mais informações, consulte concorrência.

Quando um trabalho simultâneo ou fluxo de trabalho é enfileirado, se outro trbalho ou fluxo de trabalho que usa o mesmo grupo de concorrência no repositório estiver em andamento o trabalho na fila ou o fluxo de trabalho ficará pendente. Qualquer trabalho ou fluxo de trabalho anterior pendente no grupo de concorrência será cancelado. Para cancelar também qualquer trabalho atualmente em execução ou fluxo de trabalho no mesmo grupo de concorrência, especifique cancel-in-progress: true.

Exemplos: Como usar a concorrência e o comportamento padrão

concurrency: staging_environment
concurrency: ci-${{ github.ref }}

Exemplo: Usar a concorrência para cancelar qualquer trabalho em andamento ou em execução

concurrency: 
  group: ${{ github.ref }}
  cancel-in-progress: true

Example: Using a fallback value

If you build the group name with a property that is only defined for specific events, you can use a fallback value. For example, github.head_ref is only defined on pull_request events. If your workflow responds to other events in addition to pull_request events, you will need to provide a fallback to avoid a syntax error. The following concurrency group cancels in-progress jobs or runs on pull_request events only; if github.head_ref is undefined, the concurrency group will fallback to the run ID, which is guaranteed to be both unique and defined for the run.

concurrency: 
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

Example: Only cancel in-progress jobs or runs for the current workflow

If you have multiple workflows in the same repository, concurrency group names must be unique across workflows to avoid canceling in-progress jobs or runs from other workflows. Otherwise, any previously in-progress or pending job will be canceled, regardless of the workflow.

To only cancel in-progress runs of the same workflow, you can use the github.workflow property to build the concurrency group:

concurrency: 
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs.<job_id>.outputs

You can use jobs.<job_id>.outputs to create a map of outputs for a job. As saídas de trabalho estão disponíveis para todos os trabalhos downstream que dependem deste trabalho. Para obter mais informações sobre a definição de dependências de trabalhos, consulte jobs.<job_id>.needs.

As saídas de trabalho são strings e saídas de trabalho que contêm expressões são avaliadas no executor ao final de cada trabalho. As saídas que contêm segredos são eliminadas no executor e não são enviadas para GitHub Actions.

Para usar as saídas de trabalho em um trabalho dependente, você poderá usar o contexto needs. Para obter mais informações, consulte "Contextos".

Example: Defining outputs for a job

jobs:
  job1:
    runs-on: ubuntu-latest
    # Map a step output to a job output
    outputs:
      output1: ${{ steps.step1.outputs.test }}
      output2: ${{ steps.step2.outputs.test }}
    steps:
      - id: step1
        run: echo "::set-output name=test::hello"
      - id: step2
        run: echo "::set-output name=test::world"
  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}

jobs.<job_id>.env

Um map (mapa) das variáveis de ambiente que estão disponíveis para todos as etapas do trabalho. Também é possível definir variáveis de ambiente para todo o fluxo de trabalho ou uma etapa individual. Para obter mais informações, consulte env e jobs.<job_id>.steps[*].env.

Quando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável de ambiente mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá variáveis de trabalho e de fluxo de trabalho pelo mesmo nome enquanto a etapa é executada. Uma variável definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome, enquanto o trabalho é executado.

Exemplo

jobs:
  job1:
    env:
      FIRST_NAME: Mona

jobs.<job_id>.defaults

Use jobs.<job_id>.defaults to create a map of default settings that will apply to all steps in the job. Você também pode definir as configurações-padrão para todo o fluxo de trabalho. Para obter mais informações, consulte padrão.

Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.

jobs.<job_id>.defaults.run

Use jobs.<job_id>.defaults.run to provide default shell and working-directory to all run steps in the job. Não são permitidos contexto e expressão nesta seção.

Você pode fornecer as opções-padrão de shell e working-directory para todas as etapas de execução de um trabalho. Você também pode definir as configurações-padrão para execução para todo o fluxo de trabalho. Para obter mais informações, consulte jobs.defaults.run. Você não pode usar contextos ou expressões nesta palavra-chave.

Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.

Example: Setting default run step options for a job

jobs:
  job1:
    runs-on: ubuntu-latest
    defaults:
      run:
        shell: bash
        working-directory: scripts

jobs.<job_id>.steps

Trabalhos contêm sequências de tarefas chamadas steps. As etapas podem executar comandos, executar trabalhos de configuração ou executar ações no seu repositório, em repositórios públicos, ou ações publicadas em registros do Docker. Nem todas as etapas executam ações, mas todas as ações são executadas como etapas. Cada etapa é executada em seu próprio processo no ambiente do executor, tendo acesso ao espaço de trabalho e ao sistema de arquivos. Como as etapas são executadas em seus próprios processos, as alterações nas variáveis de ambiente não são preservadas entre as etapas. O GitHub fornece etapas integradas para configurar e concluir trabalhos.

Você pode executar quantas etapas quiser, desde que esteja dentro dos limites de uso do fluxo de trabalho. Para obter mais informações, consulte "Limites de uso e cobrança" para executores hospedados em GitHub e "Sobre executores auto-hospedados" para limites de uso de executor auto-hospedado.

Exemplo

name: Greeting from Mona

on: push

jobs:
  my-job:
    name: My Job
    runs-on: ubuntu-latest
    steps:
      - name: Print a greeting
        env:
          MY_VAR: Hi there! My name is
          FIRST_NAME: Mona
          MIDDLE_NAME: The
          LAST_NAME: Octocat
        run: |
          echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

jobs.<job_id>.steps[*].id

Identificador exclusivo da etapa. Você pode usar id para fazer referência à etapa em contextos. Para obter mais informações, consulte "Contextos".

jobs.<job_id>.steps[*].if

Você pode usar a condicional if (se) para evitar que uma etapa trabalho seja executada a não ser que determinada condição seja atendida. Você pode usar qualquer contexto e expressão compatível para criar uma condicional.

Quando você usa expressões em uma condicional if você pode omitir a sintaxe da expressão (${{ }}) porque GitHub calcula automaticamente a condição if como expressão. Para obter mais informações, consulte "Expressões".

Exemplo: Usando contextos

Essa etapa somente é executada quando o tipo de evento é uma pull_request e a ação do evento é unassigned (não atribuída).

steps:
 - name: My first step
   if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
   run: echo This event is a pull request that had an assignee removed.

Exemplo: Usando funções de verificação de status

A função my backup step (minha etapa de backup) somente é executada quando houver falha em uma etapa anterior do trabalho. Para obter mais informações, consulte "Expressões".

steps:
  - name: My first step
    uses: octo-org/action-name@main
  - name: My backup step
    if: ${{ failure() }}
    uses: actions/heroku@1.0.0

jobs.<job_id>.steps[*].name

Nome da etapa no GitHub.

jobs.<job_id>.steps[*].uses

Seleciona uma ação para executar como parte de uma etapa no trabalho. A ação é uma unidade reutilizável de código. Você pode usar uma ação definida no mesmo repositório que o fluxo de trabalho, um repositório público ou em uma imagem publicada de contêiner Docker.

É altamente recomendável incluir a versão da ação que você está usando ao especificar um número de tag Docker, SHA ou ref do Git. Se você não especificar uma versão, ela poderá interromper seus fluxos de trabalho ou causar um comportamento inesperado quando o proprietário da ação publicar uma atualização.

  • Usar o commit SHA de uma versão de ação lançada é a maneira mais garantida de obter estabilidade e segurança.
  • Usar a versão principal da ação permite receber correções importantes e patches de segurança sem perder a compatibilidade. Fazer isso também garante o funcionamento contínuo do fluxo de trabalho.
  • Usar o branch-padrão de uma ação pode ser conveniente, mas se alguém lançar uma nova versão principal com uma mudança significativa, seu fluxo de trabalho poderá ter problemas.

Algumas ações requerem entradas que devem ser definidas com a palavra-chave with (com). Revise o arquivo README da ação para determinar as entradas obrigatórias.

Ações são arquivos JavaScript ou contêineres Docker. Se a ação em uso for um contêiner do Docker, você deverá executar o trabalho em um ambiente do Linux. Para obter mais detalhes, consulte runs-on.

Exemplo: Usando ações de versão

steps:
  # Reference a specific commit
  - uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675
  # Reference the major version of a release
  - uses: actions/checkout@v2
  # Reference a specific version
  - uses: actions/checkout@v2.2.0
  # Reference a branch
  - uses: actions/checkout@main

Exemplo: Usando uma ação pública

{owner}/{repo}@{ref}

É possível especificar um branch, ref, ou SHA em um repositório público de GitHub.

jobs:
  my_first_job:
    steps:
      - name: My first step
        # Uses the default branch of a public repository
        uses: actions/heroku@main
      - name: My second step
        # Uses a specific version tag of a public repository
        uses: actions/aws@v2.0.1

Exemplo: Usando uma ação pública em um subdiretório

{owner}/{repo}/{path}@{ref}

Subdiretório em um repositório público do GitHub em um branch, ref ou SHA específico.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/aws/ec2@main

Exemplo: Usando uma ação no mesmo repositório que o fluxo de trabalho

./path/to/dir

Caminho para o diretório que contém a ação no repositório do seu fluxo de trabalho. Você deve reservar seu repositório antes de usar a ação.

jobs:
  my_first_job:
    steps:
      - name: Check out repository
        uses: actions/checkout@v2
      - name: Use local my-action
        uses: ./.github/actions/my-action

Exemplo: Usando uma ação do Docker Hub

docker://{image}:{tag}

Imagem Docker publicada no Docker Hub.

empregos:
  my_first_job:
    passos:
      - nome: Meu primeiro passo
        usa: docker://alpine:3.8

Exemplo: Usando o GitHub Package Registry Container registry

docker://{host}/{image}:{tag}

Uma imagem Docker em GitHub Package Registry Container registry.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://ghcr.io/OWNER/IMAGE_NAME

Exemplo: Usando uma ação do registro público do Docker

docker://{host}/{image}:{tag}

Imagem Docker em um registro público. Este exemplo usa o Registro de Contêiner do Google em gcr.io.

jobs:
  meu_primeiro_trabalho:
    steps:
      - name: minha primeira etapa
        uses: docker://gcr.io/cloud-builders/gradle

Exemplo: Usando uma ação dentro de um repositório privado diferente do fluxo de trabalho

Seu fluxo de trabalho deve fazer checkout no repositório privado e referenciar a ação localmente. Gere um token de acesso pessoal e adicione o token como um segredo criptografado. Para obter mais informações, consulte "Criar um token de acesso pessoal" e "Segredos criptografados".

Substitua PERSONAL_ACCESS_TOKEN no exemplo pelo nome do seu segredo.

jobs:
  my_first_job:
    steps:
      - name: Check out repository
        uses: actions/checkout@v2
        with:
          repository: octocat/my-private-repo
          ref: v1.0
          token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
          path: ./.github/actions/my-private-repo
      - name: Run my action
        uses: ./.github/actions/my-private-repo/my-action

jobs.<job_id>.steps[*].run

Executa programas de linha de comando usando o shell do sistema operacional. Se você não informar um name, o nome da etapa será configurado por padrão como o texto indicado no comando run.

Por padrão, os comandos run usam shells de não login. Você pode escolher um shell diferente e personalizar o shell usado para executar comandos. Para obter mais informações, consulte trabalhos.<job_id>.steps[*].shell.

Cada palavra-chave run representa um novo processo e shell no ambiente do executor. Ao fornecer comandos de várias linhas, cada linha será executada no mesmo shell. Por exemplo:

  • Um comando de linha única:

    - name: Install Dependencies
      run: npm install
    
  • Um comando de várias linhas:

    - name: Clean install dependencies and build
      run: |
        npm ci
        npm run build
    

Com a palavra-chave working-directory (diretório de trabalho), é possível especificar o diretório de trabalho de onde o comando será executado.

- name: Clean temp directory
  run: rm -rf *
  working-directory: ./temp

jobs.<job_id>.steps[*].shell

Você pode anular as configurações padrão de shell no sistema operacional do executor usando a palavra-chave shell. É possível usar palavras-chave integradas a shell ou definir um conjunto personalizado de opções de shell. O comando do shell que é executado internamente executa um arquivo temporário que contém os comandos especificados na palavra-chave executar.

Plataforma compatívelParâmetro shellDescriçãoComando executado internamente
TodasbashO shell padrão em plataformas que não sejam Windows como uma alternativa para sh. Ao especificar um shell bash no Windows, é utilizado o shell bash incluído no Git para Windows.bash --noprofile --norc -eo pipefail {0}
TodaspwshPowershell Core. O GitHub anexa a extensão .ps1 ao nome do script.pwsh -command ". '{0}'"
TodaspythonExecuta o comando python.python {0}
Linux / macOSshComportamento alternativo para plataformas que não sejam Windows se nenhum shell for fornecido e o bash não for encontrado no caminho.sh -e {0}
WindowscmdO GitHub anexa a extensão .cmd ao nome do script e a substitui por {0}.%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"".
WindowspwshEssa é a shell padrão usada no Windows. Powershell Core. O GitHub anexa a extensão .ps1 ao nome do script. Se o seu executor do Windows auto-hospedado não tiver o PowerShell Core instalado, será usado o PowerShell Desktop.pwsh -command ". '{0}'".
WindowspowershellO PowerShell Desktop. O GitHub anexa a extensão .ps1 ao nome do script.powershell -command ". '{0}'".

Exemplo: Executando um script usando o bash

steps:
  - name: Display the path
    run: echo $PATH
    shell: bash

Exemplo: Executando um script usando cmd do Windows

steps:
  - name: Display the path
    run: echo %PATH%
    shell: cmd

Exemplo: Executando um script usando PowerShell Core

steps:
  - name: Display the path
    run: echo ${env:PATH}
    shell: pwsh

Exemplo: Usar o PowerShell Desktop para executar um script

steps:
  - name: Display the path
    run: echo ${env:PATH}
    shell: powershell

Exemplo: Executando um script do Python

steps:
  - name: Display the path
    run: |
      import os
      print(os.environ['PATH'])
    shell: python

Shell personalizado

Você pode usar o valor shell em um string modelo usando command […options] {0} [..more_options]. O GitHub interpreta a primeira palavra da string delimitada por um espaço em branco como o comando e insere o nome do arquivo para o script temporário em {0}.

Por exemplo:

steps:
  - name: Display the environment variables and their values
    run: |
      print %ENV
    shell: perl {0}

O comando usado, perl neste exemplo, deve ser instalado no executor.

Para informações sobre o software incluído nos executores hospedados no GitHub, consulte "Especificações para os executores hospedados no GitHub."

Preferências de ação de erro e códigos de saída

Para palavras-chave de shell integradas, fornecemos os seguintes padrões usados por executores hospedados no GitHub. Você deve seguir estas diretrizes quando executar scripts shell.

  • bash/sh:

    • Comportamento de falha rápido que usa set -eo pipefail: Padrão para bash e shell embutido. Também é o padrão quando você não der opção em plataformas que não sejam Windows.
    • Você pode cancelar o fail-fast e assumir o controle fornecendo uma string de modelo para as opções do shell. Por exemplo, bash {0}.
    • Shells do tipo sh saem com o código de saída do último comando executado em um script, que também é o comportamento padrão das ações. O executor relatará o status da etapa como falha/êxito com base nesse código de saída.
  • powershell/pwsh

    • Comportamento fail-fast quando possível. Para shell integrado pwsh e powershell, precederemos $ErrorActionPreference = 'stop' para conteúdos de script.
    • Vincularemos if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE } a scripts powershell para que os status da ação reflitam o código de saída mais recente do script.
    • Os usuários podem sempre optar por não usar o shell integrado e fornecer uma opção personalizada, como: pwsh -File {0} ou powershell -Command "& '{0}'", dependendo da situação.
  • cmd

    • Parece não haver uma forma de optar totalmente por um comportamento fail-fast que não seja gravar seu script para verificar cada código de erro e reagir de acordo. Como não podemos fornecer esse comportamento por padrão, você precisa gravá-lo em seu script.
    • cmd.exe sairá com o nível de erro do último programa que executou e retornará o código de erro para o executor. Este comportamento é internamente consistente o padrão de comportamento anterior sh e pwsh, e é o padrão cmd.exe; portanto, ele fica intacto.

jobs.<job_id>.steps[*].with

Um map (mapa) dos parâmetros de entrada definidos pela ação. Cada parâmetro de entrada é um par chave/valor. Parâmetros de entrada são definidos como variáveis de ambiente. A variável é precedida por INPUT_ e convertida em letras maiúsculas.

Exemplo

Define os três parâmetros de entrada (first_name, middle_name e last_name) definidos pela ação hello_world. Essas variáveis de entrada estarão acessíveis para a ação hello-world como variáveis de ambiente INPUT_FIRST_NAME, INPUT_MIDDLE_NAME e INPUT_LAST_NAME.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/hello_world@main
        with:
          first_name: Mona
          middle_name: The
          last_name: Octocat

jobs.<job_id>.steps[*].with.args

Uma string que define as entradas para um contêiner Docker. O GitHub entrega os args ao ENTRYPOINT do contêiner quando o contêiner inicia. Um array de strings não é compatível com esse parâmetro.

Exemplo

steps:
  - name: Explain why this job ran
    uses: octo-org/action-name@main
    with:
      entrypoint: /bin/echo
      args: The ${{ github.event_name }} event triggered this step.

args são usados em substituição à instrução CMD em um Dockerfile. Se você usar CMD no Dockerfile, use as diretrizes ordenadas por preferência:

  1. Documente os argumentos necessários no README das ações e omita-os da instrução CMD.
  2. Use padrões que permitam o uso da ação sem especificação de args.
  3. Se a ação expõe um sinalizador --help ou similar, use isso como padrão para que a ação se documente automaticamente.

jobs.<job_id>.steps[*].with.entrypoint

Anula o ENTRYPOINT Docker no Dockerfile ou define-o caso ainda não tenha sido especificado. Diferentemente da instrução Docker ENTRYPOINT que tem um formulário shell e exec, a palavra-chave entrypoint aceita apena uma única string que define o executável.

Exemplo

steps:
  - name: Run a custom command
    uses: octo-org/action-name@main
    with:
      entrypoint: /a/different/executable

A palavra-chave entrypoint é para ser usada com ações de contêiner Docker, mas você também pode usá-la com ações JavaScript que não definem nenhuma entrada.

jobs.<job_id>.steps[*].env

Define variáveis de ambiente para etapas a serem usadas no ambiente do executor. Também é possível definir variáveis de ambiente para todo o fluxo de trabalho ou para um trabalho. Para obter mais informações, consulte env e jobs.<job_id>.env.

Quando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável de ambiente mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá variáveis de trabalho e de fluxo de trabalho pelo mesmo nome enquanto a etapa é executada. Uma variável definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome, enquanto o trabalho é executado.

Ações públicas podem especificar variáveis de ambiente esperadas no arquivo LEIAME. Se você está configurando um segredo em uma variável de ambiente, use o contexto secrets. Para obter mais informações, consulte "Usando variáveis de ambiente" e "Contextos".

Exemplo

steps:
 - name: minha primeira ação
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    FIRST_NAME: Mona
    LAST_NAME: Octocat

jobs.<job_id>.steps[*].continue-on-error

Impede a falha de um trabalho se uma etapa não funcionar. Defina true (verdadeiro) para permitir que um trabalho aconteça quando essa etapa falhar.

jobs.<job_id>.steps[*].timeout-minutes

Número máximo de minutos para executar a etapa antes de interromper o processo.

jobs.<job_id>.timeout-minutes

Número máximo de minutos para permitir a execução de um trabalho o antes que o GitHub o cancele automaticamente. Padrão: 360

Se o tempo-limite exceder o tempo limite de execução do trabalho para o runner, o trabalho será cancelada quando o tempo limite de execução for atingido. Para obter mais informações sobre o limite de tempo de execução do trabalho, consulte "Limites de uso e cobrança" para executores hospedados em GitHub e "Sobre executores auto-hospedados" para limites de uso de executores auto-hospedados.

jobs.<job_id>.strategy

Use jobs.<job_id>.strategy to create a build matrix for your jobs. Você pode definir variações diferentes variações nas quais executar os trabalhos.

jobs.<job_id>.strategy.matrix

Use jobs.<job_id>.strategy.matrix to define a matrix of different job configurations. Uma matriz permite que você crie vários trabalhos que realizam a substituição de variável em uma definição de trabalho único. Por exemplo, você pode usar uma matriz para criar trabalhos para mais de uma versão compatível de uma linguagem de programação, sistema operacional ou ferramenta. Uma matriz reutiliza a configuração do trabalho e cria trabalho para cada matriz que você configurar.

Uma matriz de tarefas pode gerar 256 tarefas no máximo por execução do fluxo de trabalho. Este limite também se aplica a executores auto-hospedados.

Cada opção que você define na matriz tem uma chave e um valor. As chaves que você define tornam-se propriedades no contexto da matriz e você pode fazer referência à propriedade em outras áreas do seu arquivo de fluxo de trabalho. Por exemplo, se você definir a chave os que contém um array de sistemas operacionais, você poderá usar a propriedade matrix.os como o valor da palavra-chave runs-on para criar um trabalho para cada sistema operacional. Para obter mais informações, consulte "Contextos".

A ordem que você define uma matriz importa. A primeira opção que você definir será a primeira que será executada no seu fluxo de trabalho.

Exemplo: Executando várias versões do Node.js

Você pode especificar uma matriz ao fornecer um array para as opções de configuração. Por exemplo, se o executor for compatível com as versões 10, 12 e 14 do Node.js, você poderá especificar uma matriz dessas versões na matriz.

Este exemplo cria uma matriz de três trabalhos, definindo a chave para um array de três versões do Node.js. Para usar a matriz, o exemplo define a propriedade do contexto matrix.node como o valor do parâmetro setup-node de entrada da ação node-version. Como resultado, três trabalhos serão executados, cada uma usando uma versão diferente do Node.js.

strategy:
  matrix:
    node: [10, 12, 14]
steps:
  # Configures the node version used on GitHub-hosted runners
  - uses: actions/setup-node@v2
    with:
      # The Node.js version to configure
      node-version: ${{ matrix.node }}

A ação setup-node ` é a forma recomendada de configurar uma versão do Node.js ao usar executores hospedados em GitHub. Para obter mais informações, consulte a ação [setup-node`](https://github.com/actions/setup-node).

Exemplo: Executando com vários sistemas operacionais

Você pode criar uma matriz para executar fluxos de trabalho em mais de um sistema operacional do executor. Você também pode especificar mais de uma configuração da matriz. Este exemplo cria uma matriz de 6 trabalhos:

  • 2 sistemas operacionais especificados na array os
  • 3 versões do Node.js especificadas na array do

Ao definir uma matriz de sistemas operacionais, você deve definir o valor de runs-on para a propriedade de contexto de matrix.os que você definiu.

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-18.04, ubuntu-20.04]
    node: [10, 12, 14]
steps:
  - uses: actions/setup-node@v2
    with:
      node-version: ${{ matrix.node }}

Para encontrar opções de configuração compatíveis com executores hospedados em GitHub, consulte "Ambientes virtuais para executores hospedados em GitHub."

Example: Including additional values in combinations

Você pode adicionar opções de configurações para um trabalho de matriz de compilação existente. Por exemplo, se você quer usar uma versão específica do npm quando o trabalho que usa o windows-latest e a versão 8 do é executado, você pode usar incluir para especificar a opção adicional.

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [macos-latest, windows-latest, ubuntu-18.04]
    node: [8, 10, 12, 14]
    include:
      # includes a new variable of npm with a value of 6
      # for the matrix leg matching the os and version
      - os: windows-latest
        node: 8
        npm: 6

Exemplo: Incluindo novas combinações

Você pode usar incluir para adicionar novos trabalhos a uma matriz de criação. Qualquer configuração sem correspondência de incluir será adicionadas à matriz. Por exemplo, se você quiser usar a versão 14 do para compilar em vários sistemas operacionais, mas quiser uma tarefa experimental extra a versão 15 do nó no Ubuntu, você poderá usar incluir para especificar essa tarefa adicional.

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    node: [14]
    os: [macos-latest, windows-latest, ubuntu-18.04]
    include:
      - node: 15
        os: ubuntu-18.04
        experimental: true

Exemplo: Excluindo configurações de uma matriz

Você pode remover uma configuração específica definida na matriz de compilação usando a opção exclude (excluir). exclude remove um trabalho definido pela matriz de compilação. O número de trabalhos é o produto cruzado do número de sistemas operacionais (os) incluídos nos arrays fornecidos por você, menos quaisquer subtrações (exclude).

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [macos-latest, windows-latest, ubuntu-18.04]
    node: [8, 10, 12, 14]
    exclude:
      # excludes node 8 on macOS
      - os: macos-latest
        node: 8

Observação: Todas as combinações de incluir são processadas depois de excluir. Isso permite que você use incluir para voltar a adicionar combinações que foram excluídas anteriormente.

Usando variáveis de ambiente em uma matriz

Você pode adicionar variáveis de ambiente personalizadas para cada combinação de testes usando a chave include. Em seguida, você pode se referir às variáveis de ambiente personalizadas em um passo posterior.

Neste exemplo, as entradas da matriz de node-version são configuradas para usar valores diferentes para as variáveis de ambiente do site e dos centros de dados. Em seguida, a etapa de Echo site details usa env: ${{ matrix.env }} para referir-se às variáveis personalizadas:

name: Node.js CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
       include:
         - node-version: 10.x
           site: "prod"
           datacenter: "site-a"
         - node-version: 12.x
           site: "dev"
           datacenter: "site-b"
    steps:
      - name: Echo site details
        env:
          SITE: ${{ matrix.site }}
          DATACENTER: ${{ matrix.datacenter }}
        run: echo $SITE $DATACENTER

jobs.<job_id>.strategy.fail-fast

When jobs.<job_id>.strategy.fail-fast is set to true, GitHub cancels all in-progress jobs if any matrix job fails. Padrão: true

jobs.<job_id>.strategy.max-parallel

Use jobs.<job_id>.strategy.max-parallel to set the maximum number of jobs that can run simultaneously when using a matrix job strategy. Por padrão, o GitHub maximizará o número de trabalhos executados em paralelo dependendo dos executores disponíveis nas máquinas virtuais hospedadas no GitHub.

strategy:
  max-parallel: 2

jobs.<job_id>.continue-on-error

Impede que ocorra falha na execução de um fluxo de trabalho quando ocorrer uma falha em um trabalho. Defina como verdadeiro para permitir que uma execução de um fluxo de trabalho passe quando este trabalho falhar.

Exemplo: Evitando uma falha específica na matriz de trabalho por falha na execução de um fluxo de trabalho

Você pode permitir que as tarefas específicas em uma matriz de tarefas falhem sem que ocorra falha na execução do fluxo de trabalho. Por exemplo, se você deseja permitir apenas um trabalho experimental com o definido como 15 sem falhar a execução do fluxo de trabalho.

runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.experimental }}
strategy:
  fail-fast: false
  matrix:
    node: [13, 14]
    os: [macos-latest, ubuntu-18.04]
    experimental: [false]
    include:
      - node: 15
        os: ubuntu-18.04
        experimental: true

jobs.<job_id>.container

Use jobs.<job_id>.container to create a container to run any steps in a job that don't already specify a container. Se você tiver etapas que usam ações de script e de contêiner, as ações de contêiner serão executadas como contêineres irmãos na mesma rede e com as mesmas montagens de volume.

Se você não definir um container, todas as etapas serão executadas diretamente no host especificado por runs-on, a menos que uma etapa se refira a uma ação configurada para execução em um contêiner.

Example: Running a job within a container

jobs:
  my_job:
    container:
      image: node:14.16
      env:
        NODE_ENV: development
      ports:
        - 80
      volumes:
        - my_docker_volume:/volume_mount
      options: --cpus 1

Ao especificar somente uma imagem de contêiner, você pode omitir a palavra-chave image.

jobs:
  my_job:
    container: node:14.16

jobs.<job_id>.container.image

Use jobs.<job_id>.container.image to define the Docker image to use as the container to run the action. The value can be the Docker Hub image name or a registry name.

jobs.<job_id>.container.credentials

If the image's container registry requires authentication to pull the image, you can use jobs.<job_id>.container.credentials to set a map of the username and password. As credenciais são os mesmos valores que você forneceria para o comando login do docker.

Example: Defining credentials for a container registry

container:
  image: ghcr.io/owner/image
  credentials:
     username: ${{ github.actor }}
     password: ${{ secrets.ghcr_token }}

jobs.<job_id>.container.env

Use jobs.<job_id>.container.env to set a map of environment variables in the container.

jobs.<job_id>.container.ports

Use jobs.<job_id>.container.ports to set an array of ports to expose on the container.

jobs.<job_id>.container.volumes

Use jobs.<job_id>.container.volumes to set an array of volumes for the container to use. É possível usar volumes para compartilhar dados entre serviços ou outras etapas em um trabalho. Você pode especificar volumes de nome Docker, volumes Docker anônimos ou vincular montagens no host.

Para especificar um volume, especifique o caminho de origem e destino:

<source>:<destinationPath>.

<source> é um nome de volume ou caminho absoluto na máquina host, e <destinationPath> é um caminho absoluto no contêiner.

Example: Mounting volumes in a container

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

jobs.<job_id>.container.options

Use jobs.<job_id>.container.options to configure additional Docker container resource options. Para obter uma lista de opções, consulte "opções docker create".

Aviso: A opção --network não é compatível.

jobs.<job_id>.services

Nota: se seus fluxos de trabalho usam ações do contêiner Docker ou recipientes de serviço, você deve usar um executor Linux:

  • Se você estiver usando executores hospedados em GitHub, você deverá usar um executor do Ubuntu.
  • Se você estiver usando executores auto-hospedados, você deve usar uma máquina Linux, pois seu executor e o Docker precisam ser instalados.

Usado para hospedar contêineres de serviço para um trabalho em um fluxo de trabalho. Contêineres de serviço são úteis para a criação de bancos de dados ou serviços armazenamento em cache como o Redis. O executor cria automaticamente uma rede do Docker e gerencia o ciclo de vida dos contêineres do serviço.

Se você configurar seu trabalho para ser executado em um contêiner, ou a sua etapa usar ações ao contêiner, você não precisará mapear as portas para acessar o serviço ou a ação. O Docker expõe automaticamente todas as portas entre os contêineres da mesma rede de ponte definida pelo usuário. Você pode fazer referência ao contêiner de serviço diretamente pelo seu nome de host. O nome do host é mapeado automaticamente com o nome da etiqueta que você configurar para o serviço no fluxo de trabalho.

Se você configurar a tarefa para executar diretamente na máquina do executor e sua etapa não usar uma ação de contêiner, você deverá mapear todas as portas de contêiner de serviço do Docker necessárias para o host do Docker (a máquina do executor). Você pode acessar o contêiner de serviço usando host local e a porta mapeada.

Para obter mais informações sobre as diferenças entre os contêineres de serviço de rede, consulte "Sobre contêineres de serviço".

Exemplo: Usando host local

Este exemplo cria dois serviços: nginx e redis. Ao especificar a porta do host do Docker mas não a porta do contêiner, a porta do contêiner será atribuída aleatoriamente a uma porta livre. O GitHub define a porta de contêiner atribuída no contexto ${{job.services.<service_name>.ports}}. Neste exemplo, você pode acessar as portas do contêiner de serviço usando os contextos ${{ job.services.nginx.ports['8080'] }} e ${{ job.services.redis.ports['6379'] }}.

services:
  nginx:
    image: nginx
    # Map port 8080 on the Docker host to port 80 on the nginx container
    ports:
      - 8080:80
  redis:
    image: redis
    # Map TCP port 6379 on Docker host to a random free port on the Redis container
    ports:
      - 6379/tcp

jobs.<job_id>.services.<service_id>.image

Imagem Docker a ser usada como contêiner de serviço para executar a ação. O valor pode ser o nome da imagem do Docker Hub ou um nome de registro.

jobs.<job_id>.services.<service_id>.credentials

If the image's container registry requires authentication to pull the image, you can use jobs.<job_id>.container.credentials to set a map of the username and password. As credenciais são os mesmos valores que você forneceria para o comando login do docker.

Exemplo

services:
  myservice1:
    image: ghcr.io/owner/myservice1
    credentials:
      username: ${{ github.actor }}
      password: ${{ secrets.ghcr_token }}
  myservice2:
    image: dockerhub_org/myservice2
    credentials:
      username: ${{ secrets.DOCKER_USER }}
      password: ${{ secrets.DOCKER_PASSWORD }}

jobs.<job_id>.services.<service_id>.env

Define um maá das variáveis de ambiente no contêiner do serviço.

jobs.<job_id>.services.<service_id>.ports

Define um array de portas para expor no contêiner de serviço.

jobs.<job_id>.services.<service_id>.volumes

Define um array de volumes para uso do contêiner de serviço. É possível usar volumes para compartilhar dados entre serviços ou outras etapas em um trabalho. Você pode especificar volumes de nome Docker, volumes Docker anônimos ou vincular montagens no host.

Para especificar um volume, especifique o caminho de origem e destino:

<source>:<destinationPath>.

<source> é um nome de volume ou caminho absoluto na máquina host, e <destinationPath> é um caminho absoluto no contêiner.

Exemplo

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

jobs.<job_id>.services.<service_id>.options

Opções adicionais de recursos do contêiner Docker. Para obter uma lista de opções, consulte "opções docker create".

Aviso: A opção --network não é compatível.

jobs.<job_id>.uses

O local e a versão de um arquivo de fluxo de trabalho reutilizável para ser executado como job. Use one of the following syntaxes:

  • {owner}/{repo}/{path}/{filename}@{ref} for reusable workflows in public repositories.
  • ./{path}/{filename} for reusable workflows in the same repository.

{ref} can be a SHA, a release tag, or a branch name. Using the commit SHA is the safest for stability and security. For more information, see "Security hardening for GitHub Actions." If you use the second syntax option (without {owner}/{repo} and @{ref}) the called workflow is from the same commit as the caller workflow.

Exemplo

jobs:
  call-workflow-1-in-local-repo:
    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89
  call-workflow-2-in-local-repo:
    uses: ./.github/workflows/workflow-2.yml
  call-workflow-in-another-repo:
    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1

Para obter mais informações, consulte "Reutilizando fluxos de trabalho".

jobs.<job_id>.with

Quando um trabalho é usado para chamar um fluxo de trabalho reutilizável, você pode usar com para fornecer um mapa de entradas que são passadas para o fluxo de trabalho de chamada.

Qualquer entrada que você passe deve corresponder às especificações de entrada definidas no fluxo de trabalho de chamada.

Diferentemente de jobs.<job_id>.steps[*].with, as entradas que você passar com jobs.<job_id>.with não estão disponíveis como variáveis de ambiente no fluxo de trabalho de chamada. Ao invés disso, você pode fazer referência às entradas usando o contexto entrada.

Exemplo

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
    with:
      username: mona

jobs.<job_id>.with.<input_id>

Um par composto de um identificador de string para a entrada e o valor da entrada. O identificador deve corresponder ao nome de uma entrada definida por on.workflow_call.inputs.<inputs_id> no fluxo de trabalho chamado. O tipo de dado do valor deve corresponder ao tipo definido por on.workflow_call.inputs.<input_id>.type no fluxo de trabalho chamado.

Contextos de expressão permitidos: github e needs.

jobs.<job_id>.secrets

Quando um trabalho é usado para chamar um fluxo de trabalho reutilizável, você pode usar segredos para fornecer um mapa de segredos que foram passados para o fluxo de trabalho chamado.

Qualquer segredo que você passar deve corresponder aos nomes definidos no fluxo de trabalho chamado.

Exemplo

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
    secrets:
      access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}

jobs.<job_id>.secrets.<secret_id>

Um par composto por um identificador string para o segredo e o valor do segredo. O identificador deve corresponder ao nome de um segredo definido por on.workflow_call.secrets.<secret_id> no fluxo de trabalho chamado.

Contextos de expressão permitidos: github, needs e segredos.

Folha de consulta de filtro padrão

Você pode usar caracteres especiais nos filtros de caminhos, branches e tags.

  • *: Corresponde a zero ou mais caracteres, mas não corresponde ao caractere /. Por exemplo, Octo* corresponde a Octocat.
  • **: Corresponde a zero ou mais de qualquer caractere.
  • ?: Corresponde a zero ou a um dos caracteres anteriores.
  • +: Corresponde a um ou mais dos caracteres anteriores.
  • [] Corresponde a um caractere listado entre colchetes ou incluído nos intervalos. Os intervalos só podem incluir valores de a-z, A-Z, e 0-9. Por exemplo, o intervalo[0-9a-z] corresponde a qualquer letra maiúscula ou minúscula. Por exemplo, [CB]at corresponde a Cat ou Bat e [1-2]00 corresponde a 100 e 200.
  • ! No início de um padrão faz com que ele anule padrões positivos anteriores. Não tem nenhum significado especial caso não seja o primeiro caractere.

Os caracteres *, [ e ! são caracteres especiais em YAML. Se você iniciar um padrão com *, [ ou !, você deverá colocá-lo entre aspas.

# Válido
- '**/README.md'

# Inválido - Cria um erro de análise que
# impede que o seu fluxo de trabalho seja executado.
- **/README.md

Par aobte rmais informações sobre branch, tag e sintaxe de filtro do caminho, consulte "on.<push>.<branches|tags>", "on.<pull_request>.<branches|tags>" e "on.<push|pull_request>.paths."

Padrões para corresponder branches e tags

PadrãoDescriçãoExemplos de correspondências
feature/*O caractere curinga * corresponde a qualquer caractere, mas não à barra (/).feature/my-branch

feature/your-branch
feature/**** correspondem a qualquer caractere, incluindo a barra (/) em nomes de branches e tags.feature/beta-a/my-branch

feature/your-branch

feature/mona/the/octocat
main

releases/mona-the-octocat
Corresponde ao nome exato de um branch ou tag.main

releases/mona-the-octocat
'*'Corresponde a todos os nomes de branches e tags que não contêm uma barra (/). O caractere * é um caractere especial em YAML. Ao inciar um padrão com *, você deve usar aspas.main

releases
'**'Corresponde a todos os nomes de branches e tags. Esse é o comportamento padrão quando você não usa um filtro de branches ou tags.all/the/branches

every/tag
'*feature'O caractere * é um caractere especial em YAML. Ao inciar um padrão com *, você deve usar aspas.mona-feature

feature

ver-10-feature
v2*Corresponde aos nomes de branches e tags que iniciam com v2.v2

v2.0

v2.9
v[12].[0-9]+.[0-9]+Corresponde a todas as tags de versão de branch semântica com a versão principal 1 ou 2v1.10.1

v2.0.0

Padrões para corresponder a caminhos de arquivos

Padrões de caminhos devem corresponder ao caminho completo e iniciar a partir da raiz do repositório.

PadrãoDescrição das correspondênciasExemplos de correspondências
'*'O caractere curinga * corresponde a qualquer caractere, mas não à barra (/). O caractere * é um caractere especial em YAML. Ao inciar um padrão com *, você deve usar aspas.README.md

server.rb
'*.jsx?'O caractere ? corresponde a zero ou a um dos caracteres anteriores.page.js

page.jsx
'**'** corresponde a qualquer caractere incluindo a barra (/). Esse é o comportamento padrão quando você não usa um filtro de path.all/the/files.md
'*.js'O caractere curinga * corresponde a qualquer caractere, mas não à barra (/). Corresponde a todos os arquivos .js na raiz do repositório.app.js

index.js
'**.js'Corresponde a todos os arquivos .js no repositório.index.js

js/index.js

src/js/app.js
docs/*Todos os arquivos dentro da raiz do diretório docs, na raiz do repositório.docs/README.md

docs/file.txt
docs/**Qualquer arquivo no diretório docs, na raiz do repositório.docs/README.md

docs/mona/octocat.txt
docs/**/*.mdUm arquivo com um sufixo .md em qualquer local do diretório docs.docs/README.md

docs/mona/hello-world.md

docs/a/markdown/file.md
'**/docs/**'Qualquer arquivo no diretório docs, em qualquer local do repositório.docs/hello.md

dir/docs/my-file.txt

space/docs/plan/space.doc
'**/README.md'Um arquivo README.md em qualquer local do repositório.README.md

js/README.md
'**/*src/**'Qualquer arquivo em uma pasta com o sufixo src em qualquer local do repositório.a/src/app.js

my-src/code/js/app.js
'**/*-post.md'Um arquivo com o sufixo -post.md em qualquer local do repositório.my-post.md

path/their-post.md
'**/migrate-*.sql'Um arquivo com o prefixo migrate- e sufixo .sql em qualquer local do repositório.migrate-10909.sql

db/migrate-v1.0.sql

db/sept/migrate-v1.sql
*.md

!README.md
Usar um sinal de exclamação (!) na frente de um padrão o anula. Quando um arquivo corresponde a um padrão e também corresponde a um padrão negativo definido posteriormente no arquivo, o arquivo não será incluído.hello.md

Does not match

README.md

docs/hello.md
*.md

!README.md

README*
Os padrões são verificados sequencialmente. Um padrão que anula um padrão anterior irá incluir caminhos de arquivos novamente.hello.md

README.md

README.doc