Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-03-26. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Variáveis

GitHub define variáveis padrão para cada execução do fluxo de trabalho de GitHub Actions. Você também pode definir variáveis personalizadas para uso em um só fluxo de trabalho ou em vários.

Observação: no momento, não há suporte para os executores hospedados no GitHub no GitHub Enterprise Server. Você pode ver mais informações sobre o suporte futuro planejado no GitHub public roadmap.

Sobre variáveis

As variáveis fornecem uma forma de armazenar e reutilizar informações de configuração não confidenciais. Você pode armazenar quaisquer dados de configuração, como sinalizadores de compilador, nomes de usuário ou nomes de servidor como variáveis. As variáveis são interpoladas no computador que executa o fluxo de trabalho. Os comandos que são executados em ações ou etapas do fluxo de trabalho podem criar, ler e modificar variáveis.

Você pode definir variáveis personalizadas próprias ou usar as variáveis de ambiente padrão que o GitHub define automaticamente. Para obter mais informações, confira "Variáveis de ambiente padrão".

Você pode definir uma variável personalizada de duas maneiras.

Aviso: Por padrão, as variáveis são renderizadas sem máscaras nas saídas do build. Se você precisar de mais segurança para informações confidenciais, como senhas, use segredos. Para obter mais informações, confira "Usar segredos em ações do GitHub".

Definindo variáveis de ambiente para um só fluxo de trabalho

Ao definir uma variável de ambiente personalizada para um só fluxo de trabalho, é possível faze-lo usando a chave env do arquivo do fluxo de trabalho. O escopo de uma variável personalizada definida por este método fica limitado ao elemento em que ele está definido. Você pode definir variáveis cujos escopos são definidos como:

  • Todo o fluxo de trabalho, usando env no nível superior do arquivo de fluxo de trabalho.
  • O conteúdo de um trabalho em um fluxo de trabalho, usando jobs.<job_id>.env.
  • Uma etapa específica em um trabalho, usando jobs.<job_id>.steps[*].env.
YAML
name: Greeting on variable day

on:
  workflow_dispatch

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

Você pode acessar env valores de variáveis usando as variáveis de ambiente do executor ou usando contextos. O exemplo acima mostra três variáveis personalizadas usadas como variáveis de ambiente de executor em um comando echo: $DAY_OF_WEEK, $Greeting e $First_Name. Os valores e os escopos dessas variáveis são definidos no nível do fluxo de trabalho, do trabalho e da etapa, respectivamente. A interpolação dessas variáveis acontece no executor.

Os comandos nas etapas run de um fluxo de trabalho, ou uma ação referenciada, são processados pelo shell que você está usando no executor. As instruções nas outras partes de um fluxo de trabalho são processadas por GitHub Actions e não são enviadas para o executor. Você pode usar variáveis de ambiente do executor ou contextos em etapas run, mas, nas partes de um fluxo de trabalho que não são enviadas ao executor, você deve usar contextos para acessar valores de variáveis. Para obter mais informações, consulte "Usar contextos para acessar valores de variáveis".

Como a interpolação de variável de ambiente do executor é feita depois que um trabalho do fluxo de trabalho é enviado para uma máquina do executor, você deve usar a sintaxe apropriada para o shell usado no executor. Neste exemplo, o fluxo de trabalho especifica ubuntu-latest. Por padrão, os executores do Linux usam o shell do Bash. Portanto, você precisa usar a sintaxe $NAME. Por padrão, os executores do Windows usam o PowerShell, então, você usaria a sintaxe $env:NAME. Para saber mais sobre shells, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Convenções de nomenclatura para variáveis de ambiente

Ao definir uma variável de ambiente, você não pode usar nenhum dos nomes das variáveis de ambiente padrão. Para obter uma lista completa das variáveis de ambiente padrão, confira "Variáveis de ambiente padrão", abaixo. Se você tentar substituir o valor de uma dessas variáveis padrão, a atribuição será ignorada.

Qualquer nova variável que você definir e apontar para uma localização no sistema de arquivos deverá ter um sufixo _PATH. As variáveis padrão GITHUB_ENV e GITHUB_WORKSPACE são exceções a essa convenção.

Observação: você pode listar todo o conjunto de variáveis de ambiente disponíveis para uma etapa de fluxo de trabalho usando run: env em uma etapa e examinando a saída da etapa.

Como definir variáveis de configuração para vários fluxos de trabalho

Nota: as variáveis de configuração de GitHub Actions estão em versão beta e sujeitas a alterações.

Você pode criar variáveis de configuração para uso em vários fluxos de trabalho e pode defini-las no nível da organização, do repositório ou do ambiente.

Por exemplo, você pode usar variáveis de configuração para definir valores padrão a parâmetros passados para criar ferramentas no nível da organização, mas permitir que os proprietários de repositório substituam esses parâmetros caso a caso.

Quando você define variáveis de configuração, elas ficam automaticamente disponíveis no contexto vars. Para obter mais informações, confira "Como usar o varscontexto para acessar valores de variáveis de configuração".

Precedência da variável de configuração

Se houver uma variável com mesmo nome em vários níveis, a variável do nível mais baixo terá precedência. Por exemplo, se uma variável no nível da organização tiver o mesmo nome que uma no nível do repositório, a segunda terá precedência. Da mesma forma, se uma organização, um repositório e um ambiente tiverem uma variável com mesmo nome, àquela no nível do ambiente terá precedência.

Para fluxos de trabalho reutilizáveis, são usadas as variáveis do repositório do fluxo de trabalho do chamador. As variáveis do repositório que contém o fluxo de trabalho chamado não são disponibilizadas para o fluxo de trabalho do chamador.

Convenções de nomenclatura para variáveis de configuração

As seguintes regras se aplicam aos nomes de variáveis de configuração:

  • Os nomes só podem conter caracteres alfanuméricos ([a-z], [A-Z], [0-9]) ou sublinhados (_). Espaços não são permitidos.
  • Os nomes não devem começar com o prefixo GITHUB_.
  • Os nomes não devem começar com número.
  • Os nomes não diferenciam maiúsculas de minúsculas.
  • Os nomes devem ser únicos no nível em que são criados.

Criando variáveis de configuração para um repositório

Para criar segredos ou variáveis no GitHub para um repositório de conta pessoal, você deve ser o proprietário do repositório. Para criar segredos ou variáveis no GitHub para um repositório de organização, você deve ter acesso a admin. Por fim, para criar segredos ou variáveis para um repositório de conta pessoal ou um repositório de organização por meio da API REST, você deve ter acesso de colaborador.

  1. No sua instância do GitHub Enterprise Server, navegue até a página principal do repositório.

  2. Abaixo do nome do repositório, clique em Configurações. Caso não consiga ver a guia "Configurações", selecione o menu suspenso , clique em Configurações.

    Captura de tela de um cabeçalho de repositório que mostra as guias. A guia "Configurações" é realçada por um contorno laranja-escuro.

  3. Na seção "Segurança" da barra lateral, selecione Segredos e variáveis, e clique em Ações.

  4. Clique na guia Variáveis. Captura de tela da página "Segredos e variáveis de ações". A guia "Variáveis" é realçada com um contorno laranja escuro.

  5. Clique em Nova variável de repositório.

  6. No campo Nome, insira um nome para sua variável.

  7. No campo Valor, insira o valor da variável.

  8. Clique em Adicionar variável.

Como criar variáveis de configuração para um ambiente

Para criar segredos ou variáveis para um ambiente em um repositório de conta pessoal, você precisa ser o proprietário do repositório. Para criar segredos ou variáveis para um ambiente no repositório de uma organização, você precisa ter acesso de admin. Para saber mais sobre os ambientes, confira "Usando ambientes para implantação".

  1. No sua instância do GitHub Enterprise Server, navegue até a página principal do repositório.

  2. Abaixo do nome do repositório, clique em Configurações. Caso não consiga ver a guia "Configurações", selecione o menu suspenso , clique em Configurações.

    Captura de tela de um cabeçalho de repositório que mostra as guias. A guia "Configurações" é realçada por um contorno laranja-escuro.

  3. Na barra lateral esquerda, clique em Ambientes.

  4. Clique no ambiente ao qual deseja adicionar uma variável.

  5. Em Variáveis de ambiente, clique em Adicionar variável.

  6. No campo Nome, insira um nome para sua variável.

  7. No campo Valor, insira o valor da variável.

  8. Clique em Adicionar variável.

Como criar variáveis de configuração para uma organização

Ao criar um segredo ou uma variável em uma organização, você poderá usar uma política para limitar o acesso por repositório. Por exemplo, você pode conceder acesso a todos os repositórios ou limitar o acesso a apenas repositórios privados ou a uma lista específica de repositórios.

Os proprietários da organização podem criar segredos ou variáveis no nível da organização.

  1. No sua instância do GitHub Enterprise Server, navegue até a página principal da organização.

  2. No nome da sua organização, clique Configurações. Caso não consiga ver a guia "Configurações", selecione o menu suspenso , clique em Configurações.

    Captura de tela das guias no perfil de uma organização. A guia "Configurações" está contornada em laranja escuro.

  3. Na seção "Segurança" da barra lateral, selecione Segredos e variáveis, e clique em Ações.

  4. Clique na guia Variáveis.

    Captura de tela da página "Segredos e variáveis de ações". Uma guia, rotulada como "Variáveis", está contornada em laranja escuro.

  5. Clique em Nova variável de organização.

  6. No campo Nome, insira um nome para sua variável.

  7. No campo Valor, insira o valor da variável.

  8. Na lista suspensa Acesso do repositório, escolha uma política de acesso.

  9. Clique em Adicionar variável.

Limites para variáveis de configuração

As variáveis individuais são limitadas a 48 KB.

Você pode armazenar até 1.000 variáveis por organização, 100 variáveis por repositório e 100 variáveis por ambiente.

Um fluxo de trabalho criado em um repositório pode acessar o seguinte número de variáveis:

  • Todas as 100 variáveis de repositório.
  • Se o repositório tiver acesso a mais de 100 variáveis de organização, o fluxo de trabalho só poderá usar as primeiras 100 (ordenadas alfabeticamente pelo nome).
  • Todas as 100 variáveis de nível de ambiente.

Como usar contextos para acessar valores de variáveis

Os contextos são uma forma de acessar informações sobre execuções de fluxo de trabalho, variáveis, ambientes dos executores, trabalhos e etapas. Para obter mais informações, confira "Contextos". Há muitos outros contextos que você pode usar para uma série de finalidades nos seus fluxos de trabalho. Para obter detalhes sobre quando usar contextos específicos em um fluxo de trabalho, confira "Contextos".

Você pode acessar valores de variáveis de ambiente usando o contexto env e valores de variáveis de configuração usando o contexto vars.

Como usar o contexto env para acessar valores de variáveis de ambiente

Além das variáveis de ambiente do executor, GitHub Actions permite que você defina e leia valores da chave env usando contextos. As variáveis e os contextos do ambiente são destinados a serem usados em diferentes pontos do fluxo de trabalho.

As etapas run em um fluxo de trabalho ou em uma ação referenciada são processadas por um executor. Como resultado, você pode usar variáveis de ambiente de executor aqui, usando a sintaxe apropriada para o shell que você está usando no executor; por exemplo, $NAME para o shell bash em um executor do Linux ou $env:NAME para o PowerShell em um executor do Windows. Na maioria dos casos, você também pode usar contextos, com a sintaxe ${{ CONTEXT.PROPERTY }}, para acessar o mesmo valor. A diferença é que o contexto será interpolado e substituído por uma cadeia de caracteres antes que o trabalho seja enviado a um executor.

No entanto, não é possível usar variáveis de ambiente do executor em partes de um fluxo de trabalho que são processadas pelo GitHub Actions e não são enviadas ao executor. Em vez disso, você deve usar contextos. Por exemplo, um condicional if, que determina se uma etapa ou um trabalho é enviado ao executor, sempre será processado pelo GitHub Actions. Portanto, você deve usar um contexto em uma instrução condicional if para acessar o valor de uma variável.

YAML
name: Conditional env variable

on: workflow_dispatch

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        if: ${{ env.DAY_OF_WEEK == 'Monday' }}
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

Nessa modificação do exemplo anterior, introduzimos um if condicional. A etapa de fluxo de trabalho agora só será executada se DAY_OF_WEEK estiver definido como "Segunda-feira". Acessamos esse valor por meio da instrução condicional if usando o contexto env. O contexto env não é necessário para as variáveis referenciadas no comando run. Elas são referenciadas como variáveis de ambiente do executor e são interpoladas depois que o trabalho é recebido pelo executor. No entanto, poderíamos ter optado por interpolar essas variáveis antes de enviar o trabalho ao executor, usando contextos. A saída resultante seria a mesma.

run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!"

Observação: os contextos geralmente são indicados pelo sinal de cifrão e chaves, como ${{ context.property }}. Em um condicional if, o ${{ e o }} são opcionais, mas se você usá-los, eles precisarão incluir toda a instrução de comparação, conforme mostrado acima.

Normalmente, você usará o contexto env ou github para acessar valores de variáveis em partes do fluxo de trabalho processadas antes que os trabalhos sejam enviados aos executores.

ContextoCaso de usoExemplo
envVariáveis personalizadas de referência definidas no fluxo de trabalho.${{ env.MY_VARIABLE }}
githubInformações de referência sobre a execução do fluxo de trabalho e o evento que acionou a execução.${{ github.repository }}

Aviso: ao criar fluxos de trabalho e ações, você sempre deve considerar se o seu código pode executar entradas não confiáveis de possíveis invasores. Certos contextos devem ser tratados como entradas não confiáveis, uma vez que um invasor pode inserir seu próprio conteúdo malicioso. Para obter mais informações, confira "Fortalecimento de segurança para o GitHub Actions".

Como usar o contexto vars para acessar valores de variáveis de configuração

As variáveis de configuração podem ser acessadas em todo o fluxo de trabalho usando o contexto vars. Para obter mais informações, confira "Contextos".

Se uma variável de configuração não tiver sido definida, o valor retornado de um contexto referenciando a variável será uma cadeia de caracteres vazia.

O exemplo a seguir mostra o uso de variáveis de configuração com o contexto vars em um fluxo de trabalho. Cada uma das variáveis de configuração a seguir foram definidas no nível do repositório, da organização ou do ambiente.

YAML
on:
  workflow_dispatch:
env:
  # Setting an environment variable with the value of a configuration variable
  env_var: ${{ vars.ENV_CONTEXT_VAR }}

jobs:
  display-variables:
    name: ${{ vars.JOB_NAME }}
    # You can use configuration variables with the `vars` context for dynamic jobs
    if: ${{ vars.USE_VARIABLES == 'true' }}
    runs-on: ${{ vars.RUNNER }}
    environment: ${{ vars.ENVIRONMENT_STAGE }}
    steps:
    - name: Use variables
      run: |
        echo "repository variable : $REPOSITORY_VAR"
        echo "organization variable : $ORGANIZATION_VAR"
        echo "overridden variable : $OVERRIDE_VAR"
        echo "variable from shell environment : $env_var"
      env:
        REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
        ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
        OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
        
    - name: ${{ vars.HELLO_WORLD_STEP }}
      if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
      uses: actions/hello-world-javascript-action@main
      with:
        who-to-greet: ${{ vars.GREET_NAME }}

Variáveis de ambiente padrão

As variáveis de ambiente padrão que os conjuntos de GitHub estão disponíveis para cada etapa de um fluxo de trabalho.

Como as variáveis de ambiente padrão são definidas por GitHub e não são definidas em um fluxo de trabalho, elas não são acessíveis por meio do contexto de env. No entanto, a maioria das variáveis padrão tem uma propriedade de contexto correspondente e nomeada de modo semelhante. Por exemplo, o valor da variável GITHUB_REF pode ser lido durante o processamento do fluxo de trabalho por meio da propriedade de contexto ${{ github.ref }}.

Não é possível substituir o valor das variáveis de ambiente padrão chamadas GITHUB_* e RUNNER_*. Atualmente, você pode substituir o valor da variável CI. No entanto, não é garantido que isso sempre será possível. Para obter mais informações sobre como definir variáveis de ambiente, consulte "Definir variáveis de ambiente para um único fluxo de trabalho" e "Comandos de fluxo de trabalho para o GitHub Actions".

É altamente recomendável que as ações usem variáveis para acessar o sistema do arquivo em vez de usar caminhos de arquivo embutidos no código. O GitHub define as variáveis para ações a serem usadas em todos os ambientes do executor.

VariávelDescrição
CISempre defina como true.
GITHUB_ACTIONO nome da ação atualmente em execução ou a id de uma etapa. Por exemplo, para uma ação, __repo-owner_name-of-action-repo.

O GitHub remove caracteres especiais ou usa o nome __run quando a etapa atual executa um script sem uma id. Se você usar o mesmo script ou ação mais de uma vez no mesmo trabalho, o nome incluirá um sufixo que consiste do número de sequência precedido por um sublinhado. Por exemplo, o primeiro script que você executar terá o nome __run, e o segundo script será chamado __run_2. Da mesma forma, a segunda invocação de actions/checkout será actionscheckout2.
GITHUB_ACTION_PATHO caminho onde uma ação está localizada. Esta propriedade só é compatível com ações compostas. Você pode usar este caminho para mudar os diretórios onde a ação está localizada e acessar outros arquivos localizados no mesmo repositório da ação. Por exemplo, /home/runner/work/_actions/repo-owner/name-of-action-repo/v1.
GITHUB_ACTION_REPOSITORYPara uma etpa que executa uma ação, este é o nome do proprietário e do repositório da ação. Por exemplo, actions/checkout.
GITHUB_ACTIONSDefina isso sempre como truequando o GitHub Actions estiver executando o fluxo de trabalho. Você pode usar esta variável para diferenciar quando os testes estão sendo executados localmente ou por GitHub Actions.
GITHUB_ACTORNome da pessoa ou aplicativo que iniciou o fluxo de trabalho. Por exemplo, octocat.
GITHUB_API_URLRetorna a URL da API. Por exemplo: http(s)://HOSTNAME/api/v3.
GITHUB_BASE_REFO nome de referência da base ou o branch de destino da solicitação de pull na execução de um fluxo de trabalho. Isso só é definido quando o evento que dispara uma execução de fluxo de trabalho é pull_request ou pull_request_target. Por exemplo, main.
GITHUB_ENVO caminho no executor para o arquivo que define as variáveis por meio de comandos do fluxo de trabalho. Este arquivo é único para a etapa atual e alterações para cada etapa de um trabalho. Por exemplo, /home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a. Para obter mais informações, confira "Comandos de fluxo de trabalho para o GitHub Actions".
GITHUB_EVENT_NAMENome do evento que acionou a execução do fluxo de trabalho. Por exemplo, workflow_dispatch.
GITHUB_EVENT_PATHO caminho para o arquivo no executor que contém a carga completa do webhook do evento. Por exemplo, /github/workflow/event.json.
GITHUB_GRAPHQL_URLRetorna a URL da API do GraphQL. Por exemplo: http(s)://HOSTNAME/api/graphql.
GITHUB_HEAD_REFA referência principal ou o branch da fonte da solicitação de pull na execução de um fluxo de trabalho. Essa propriedade só é definida quando o evento que dispara uma execução de fluxo de trabalho é pull_request ou pull_request_target. Por exemplo, feature-branch-1.
GITHUB_JOBA job_id do trabalho atual. Por exemplo, greeting_job.
GITHUB_OUTPUTO caminho no executor para o arquivo que define as saídas da etapa atual a partir de comandos do fluxo de trabalho. Este arquivo é único para a etapa atual e alterações para cada etapa de um trabalho. Por exemplo, /home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0. Para obter mais informações, confira "Comandos de fluxo de trabalho para o GitHub Actions".
GITHUB_PATHO caminho no executor para o arquivo que define as variáveis PATH do sistema por meio dos comandos do fluxo de trabalho. Este arquivo é único para a etapa atual e alterações para cada etapa de um trabalho. Por exemplo, /home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5. Para obter mais informações, confira "Comandos de fluxo de trabalho para o GitHub Actions".
GITHUB_REFA ref totalmente formada do branch ou tag que acionou a execução do fluxo de trabalho. Para fluxos de trabalho disparados por push, esse é o branch ou a ref da tag que foi enviada por push. Para fluxos de trabalho disparados por pull_request, esse é o branch de mesclagem de solicitação de pull. Para fluxos de trabalho disparados por release, essa é a tag de versão criada. Para outros gatilhos, esse é o branch ou a ref de tag que disparou a execução do fluxo de trabalho. Essa variável só é definida quando há um branch ou uma tag disponível para o tipo de evento. A ref fornecida tem o formato completo, o que significa que, para branches, o formato é refs/heads/<branch_name>, para solicitações de pull é refs/pull/<pr_number>/merge e para tags é refs/tags/<tag_name>. Por exemplo, refs/heads/feature-branch-1.
GITHUB_REF_NAMEO nome de ref curto do branch ou tag que acionou a execução do fluxo de trabalho. Esse valor corresponde ao nome do branch ou tag mostrado em GitHub. Por exemplo, feature-branch-1.

Para solicitações de pull, o formato é <pr_number>/merge.
GITHUB_REF_PROTECTEDtrue se proteções de ramificação estiverem configurados para a referência que disparou a execução do fluxo de trabalho.
GITHUB_REF_TYPEO tipo de ref que acionou a execução do fluxo de trabalho. Os valores válidos são branch ou tag.
GITHUB_REPOSITORYO nome do proprietário e do repositório. Por exemplo, octocat/Hello-World.
GITHUB_REPOSITORY_OWNERO nome do proprietário do repositório. Por exemplo, octocat.
GITHUB_RETENTION_DAYSO número de dias que os logs e artefatos de execução do fluxo de trabalho são mantidos. Por exemplo, 90.
GITHUB_RUN_ATTEMPTUm número exclusivo para cada tentativa de execução de um fluxo de trabalho específico em um repositório. Este número começa em 1 para a primeira tentativa de execução do fluxo de trabalho e aumenta a cada nova execução. Por exemplo, 3.
GITHUB_RUN_IDUm número exclusivo para cada fluxo de trabalho executado em um repositório. Este número não muda se você executar novamente o fluxo de trabalho. Por exemplo, 1658821493.
GITHUB_RUN_NUMBERUm número exclusivo para cada execução de um fluxo de trabalho específico em um repositório. Esse número começa em 1 para a primeira execução do fluxo de trabalho e é incrementado a cada nova operação. Este número não muda se você executar novamente o fluxo de trabalho. Por exemplo, 3.
GITHUB_SERVER_URLA URL do servidor do GitHub Enterprise Server. Por exemplo: https://HOSTNAME.
GITHUB_SHAO commit SHA que acionou o fluxo de trabalho. O valor do commit deste SHA depende do evento que acionou o fluxo de trabalho. Para obter mais informações, confira "Eventos que disparam fluxos de trabalho". Por exemplo, ffac537e6cbbf934b08745a378932722df287a53.
GITHUB_STEP_SUMMARYO caminho no executor para o arquivo que contém resumos de tarefas de comandos de fluxo de trabalho. Este arquivo é único para a etapa atual e alterações para cada etapa de um trabalho. Por exemplo, /home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c. Para obter mais informações, confira "Comandos de fluxo de trabalho para o GitHub Actions".
GITHUB_TRIGGERING_ACTORO nome de usuário de quem iniciou a execução do fluxo de trabalho. Se a execução do fluxo de trabalho for executada novamente, esse valor poderá ser diferente de github.actor. Qualquer nova execução de fluxo de trabalho usará os privilégios de github.actor, mesmo que o ator que inicie a nova execução (github.triggering_actor) tenha privilégios diferentes.
GITHUB_WORKFLOWO nome do fluxo de trabalho. Por exemplo, My test workflow. Se o arquivo de fluxo de trabalho não especificar um name, o valor dessa variável será o caminho completo do arquivo de fluxo de trabalho no repositório.
GITHUB_WORKSPACEO diretório de trabalho padrão no executor para as etapas e o local padrão do repositório ao usar a ação checkout. Por exemplo, /home/runner/work/my-repo-name/my-repo-name.
RUNNER_ARCHA arquitetura do executor que está executando o trabalho. Os valores possíveis são X86, X64, ARM ou ARM64.
RUNNER_DEBUGIsso será definido somente se o log de depuração estiver habilitado e sempre tiver o valor de 1. Pode ser útil como um indicador para habilitar a depuração adicional ou o log detalhado em suas etapas de trabalho.
RUNNER_NAMEO nome do executor que executa a tarefa. Esse nome pode não ser exclusivo em uma execução de fluxo de trabalho, pois os executores nos níveis de repositório e organização podem usar o mesmo nome. Por exemplo, Hosted Agent
RUNNER_OSO sistema operacional do executor que está executando o trabalho. Os valores possíveis são Linux, Windows, ou macOS. Por exemplo, Windows
RUNNER_TEMPO caminho para um diretório temporário no executor. Este diretório é esvaziado no início e no final de cada trabalho. Observe que os arquivos não serão removidos se a conta de usuário do executor não tiver permissão para excluí-los. Por exemplo, D:\a\_temp
RUNNER_TOOL_CACHEO caminho para o diretório que contém ferramentas pré-instaladas para executores hospedados em GitHub. Para obter mais informações, confira "Usar executores hospedados no GitHub". Por exemplo, C:\hostedtoolcache\windows

Observação: caso precise usar um URL de execução de fluxo de trabalho em um cargo, combine estas variáveis: $GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID

Detectando o sistema operacional

Você pode escrever um arquivo de fluxo de trabalho individual que pode ser usado para diferentes sistemas operacionais usando a variável de ambiente RUNNER_OS padrão e a propriedade de contexto correspondente ${{ runner.os }}. Por exemplo, o fluxo de trabalho a seguir poderá ser executado com sucesso se você alterar o sistema operacional de macos-latest para windows-latest sem precisar alterar a sintaxe das variáveis de ambiente, que varia conforme o shell que está sendo usado pelo executor.

YAML
on: workflow_dispatch

jobs:
  if-Windows-else:
    runs-on: macos-latest
    steps:
      - name: condition 1
        if: runner.os == 'Windows'
        run: echo "The operating system on the runner is $env:RUNNER_OS."
      - name: condition 2
        if: runner.os != 'Windows'
        run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."

Neste exemplo, as duas instruções if verificam a propriedade os do contexto runner para determinar o sistema operacional do executor. Os condicionais if são processados pelo GitHub Actions, e somente as etapas em que a verificação resolve como true são enviadas ao executor. Aqui, uma das verificações sempre será true e a outra false. Portanto, apenas uma dessas etapas será enviada ao executor. Assim que o trabalho for enviado ao executor, a etapa será executada e a variável de ambiente no comando echo será interpolada com a sintaxe apropriada ($env:NAME para o PowerShell no Windows e $NAME para o Bash e o sh no Linux e no macOS). Neste exemplo, a instrução runs-on: macos-latest significa que a segunda etapa será executada.

Passando valores entre etapas e trabalhos em um fluxo de trabalho

Se você gerar um valor em uma etapa de um trabalho, poderá usar o valor em etapas posteriores do mesmo trabalho atribuindo o valor a uma variável de ambiente nova ou existente e gravando isso no arquivo de ambiente GITHUB_ENV. O arquivo de ambiente pode ser usado diretamente por uma ação ou em um comando do shell no arquivo de fluxo de trabalho usando a palavra-chave run. Para obter mais informações, confira "Comandos de fluxo de trabalho para o GitHub Actions".

Se você deseja passar um valor de uma etapa de um trabalho em um fluxo de trabalho para uma etapa de outro trabalho no fluxo de trabalho, você poderá definir o valor como uma saída de trabalho. Em seguida, você poderá fazer referência a saída desse trabalho a partir de uma etapa em outro trabalho. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".