Sobre ambientes
Os ambientes são usados para descrever um destino de implantação geral, como production
, staging
ou development
. Quando um fluxo de trabalho de GitHub Actions é implantado em um ambiente, o ambiente é exibido na página principal do repositório. Para obter mais informações sobre como ver implantações em ambientes, confira "Exibir o histórico de implantações."
Você pode configurar ambientes com regras de proteção e segredos. Quando um trabalho de fluxo de trabalho faz referência a um ambiente, o trabalho não será iniciado até que todas as regras de proteção do ambiente sejam aprovadas. Um trabalho também não pode acessar segredos definidos em um ambiente até que todas as regras de proteção da implantação tenham êxito.
Opcionalmente, você pode ignorar as regras de proteção de um ambiente e forçar que todos os trabalhos pendentes que fazem referência a ele prossigam. Para obter mais informações, confira "Revisar implantações".
Observação: os usuários com planos de GitHub Free só podem configurar ambientes para repositórios públicos. Se você converter um repositório de público em privado, todas as regras de proteção ou segredos de ambiente configurados serão ignorados, e você não conseguirá configurar nenhum ambiente. Se você converter seu repositório de volta para público, você terá acesso a todas as regras de proteção e segredos de ambiente previamente configurados.
Organizações com GitHub Team e usuários com GitHub Pro podem configurar ambientes para repositórios privados. Para obter mais informações, confira "Planos do GitHub".
Regras de proteção de implantação
As normas de proteção de implantação exigem a aprovação de condições específicas antes que um trabalho que faz referência ao ambiente possa prosseguir. Você pode usar regras de proteção de implantação para exigir uma aprovação manual, atrasar um trabalho ou restringir o ambiente a determinadas ramificações. Você também pode criar e implementar regras de proteção personalizadas desenvolvidas pelo GitHub Apps para usar sistemas de terceiros no controle de implantações que fazem referência a ambientes configurados no GitHub.
Os sistemas de terceiros podem ser sistemas de observabilidade, sistemas de gerenciamento de alterações, sistemas de qualidade de código ou outras configurações manuais que você usa para avaliar a prontidão antes que as implantações sejam implementadas com segurança nos ambientes.
Observação: Qualquer número de regras de proteção de implementação baseadas no GitHub Apps pode ser instalado em um repositório. No entanto, no máximo seis regras de proteção de implantação podem ser habilitadas em qualquer ambiente ao mesmo tempo.
Revisores necessários
Use os revisores necessários para exigir que uma pessoa ou equipe específica aprove os trabalhos do fluxo de trabalho que fazem referência ao ambiente. Você pode listar até seis usuários ou equipes como revisores. Os revisores devem ter, pelo menos, acesso de leitura ao repositório. Apenas um dos revisores precisam aprovar o trabalho para que prossiga.
Você também tem a opção de impedir auto-revisões para implementações em ambientes protegidos. Se você habilitar essa configuração, os usuários que iniciarem uma implantação não poderão aprovar o trabalho de implantação, mesmo que sejam revisores obrigatórios. Isso garante que as implementações em ambientes protegidos sejam sempre revisadas por mais de uma pessoa.
Para obter mais informações sobre como revisar trabalhos que referenciam um ambiente com revisores obrigatórios, confira "Revisar implantações."
Observação: se você estiver em um plano GitHub Free, GitHub Pro ou GitHub Team, os revisores obrigatórios estarão disponíveis apenas para repositórios públicos.
Temporizador de espera
Use o temporizador de espera para atrasar o trabalho por um período específico de tempo depois que o trabalho for inicialmente acionado. O tempo (em minutos) deve ser um número inteiro entre 1 e 43.200 (30 dias).
Observação: se você estiver em um plano GitHub Free, GitHub Pro ou GitHub Team, os temporizadores de espera estarão disponíveis apenas para repositórios públicos.
Ramificações de implantação e marcas
Use ramificações de implantação e marcas para restringir quais ramificações e marcas podem ser implantadas no ambiente. A seguir estão as opções para ramificações de implantação e marcas para um ambiente:
-
Sem restrição: nenhuma restrição sobre qual ramificação ou marca pode ser implantada no ambiente.
-
Apenas ramificações protegidas: apenas ramificações com regras de proteção de ramificação habilitadas podem ser implantadas no ambiente. Se nenhuma regra de proteção de branch for definida para qualquer branch no repositório, todos os branches poderão implantar. Para obter mais informações sobre regras de proteção de branches, consulte "Sobre branches protegidos".
Observação: as execuções de fluxo de trabalho de implantação acionadas por tags com o mesmo nome de um branch protegido e forks com branches que correspondem ao nome do branch protegido não podem ser implantadas no ambiente.
-
Ramificações selecionadas e marcas: somente ramificações e marcas que correspondam aos padrões de nome especificados podem ser implantadas no ambiente.
Se você especificar
releases/*
como uma regra de ramificação de implantação ou marca, apenas uma ramificação ou marca cujo nome comece comreleases/
poderá ser implantada no ambiente. (Os caracteres curinga não corresponderão a/
. Para fazer a correspondência de ramificações ou marcas que começam comrelease/
e contêm uma barra única adicional, userelease/*/*
.) Se você adicionarmain
como uma regra de ramificação, uma ramificação chamadamain
também poderá ser implantada no ambiente. Para obter mais informações sobre opções de sintaxe para ramificações de implantação, consulte a documentação do RubyFile.fnmatch
.Observação: os padrões de nomes devem ser configurados individualmente para ramificações ou marcas.
Observação: ramificações de implantação e marcas estão disponíveis para todos os repositórios públicos. Para usuários dos planos GitHub Pro ou GitHub Team, ramificações de implantação e marcas também estão disponíveis para repositórios privados.
Permitir que os administradores ignorem as regras de proteção configuradas
Por padrão, os administradores podem ignorar as regras de proteção e forçar implantações para ambientes específicos. Para obter mais informações, confira "Revisar implantações".
Como alternativa, você pode configurar ambientes para não permitir ignorar as regras de proteção para todas as implantações no ambiente.
Nota: a permissão para administradores ignorarem as regras de proteção só estão disponíveis em repositórios públicos para usuários dos planos GitHub Free, GitHub Pro e GitHub Team.
Regras de proteção de implantação personalizadas
Nota: regras de proteção de implementação personalizada estão atualmente em versão prévia pública e sujeitas a alterações.
Você pode habilitar suas próprias regras de proteção personalizadas para bloquear implantações com serviços de terceiros. Por exemplo, você pode usar serviços como Datadog, Honeycomb e ServiceNow para fornecer aprovações automatizadas para implantações no GitHub.com. Para obter mais informações, confira "Criar regras de proteção de implantação personalizadas".
Depois que as regras de proteção de implantação personalizadas forem criadas e instaladas em um repositório, você poderá habilitar a regra de proteção de implantação personalizada para qualquer ambiente no repositório. Para obter mais informações sobre como configurar e habilitar regras de proteção de implantação personalizadas, confira "Configurar regras de proteção de implantação personalizadas".
Nota: as regras de proteção de implantação personalizadas só estão disponíveis em repositórios públicos para usuários dos planos GitHub Free, GitHub Pro e GitHub Team.
Segredos do ambiente
Os segredos armazenados em um ambiente só estão disponíveis para trabalhos de fluxo de trabalho que fazem referência ao ambiente. Se o ambiente exigir aprovação, um trabalho não poderá acessar segredos de ambiente até que um dos revisores necessários o aprove. Para obter mais informações sobre segredos, confira "Usar segredos em ações do GitHub".
Observações:
- Os fluxos de trabalho executados em executores auto-hospedados não são executados em um contêiner isolado, mesmo que usem ambientes. Os segredos de ambiente devem ser tratados com o mesmo nível de segurança que os segredos do repositório e da organização. Para obter mais informações, confira "Fortalecimento de segurança para o GitHub Actions".
- Os segredos de ambiente só estarão disponíveis em repositórios públicos se você estiver usando o GitHub Free. Para acesso aos segredos de ambiente em repositórios privados ou internos, use o GitHub Pro, o GitHub Team ou o GitHub Enterprise. Para saber mais sobre como alternar seu plano, confira "Atualizando o plano da sua conta".
Variáveis de ambiente
As variáveis armazenadas em um ambiente só ficam disponíveis para trabalhos de fluxos de trabalho que fazem referência ao ambiente. Essas variáveis só podem ser acessadas usando o contexto vars
. Para obter mais informações, confira "Armazenar informações em variáveis".
Nota: as variáveis de ambiente estão disponíveis para todos os repositórios públicos. Para usuários dos planos GitHub Pro ou GitHub Team, as variáveis de ambiente também estão disponíveis para repositórios privados.
Criando um ambiente
Para configurar um ambiente em um repositório de conta pessoal, você deve ser o proprietário do repositório. Para configurar um ambiente em um repositório da organização, você precisa ter acesso de admin
.
Observações:
- A criação de um ambiente em um repositório privado está disponível para organizações com GitHub Team e usuários com GitHub Pro.
- Alguns recursos para ambientes não têm disponibilidade ou proporcionam disponibilidade limitada para repositórios privados. Se você não conseguir acessar um recurso descrito nas instruções abaixo, confira a documentação vinculada na etapa relacionada para obter as informações de disponibilidade.
-
Em GitHub, acesse a página principal do repositório.
-
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.
-
Na barra lateral esquerda, clique em Ambientes.
-
Clique em Novo ambiente.
-
Insira um nome para o ambiente e clique em Configurar ambiente. Os nomes de ambiente não diferenciam maiúsculas de minúsculas. Um nome de ambiente não pode exceder 255 caracteres e deve ser único dentro do repositório.
-
Opcionalmente, especifique as pessoas ou equipes que devem aprovar os trabalhos do fluxo de trabalho que usam esse ambiente. Para obter mais informações, confira "Revisores necessários".
- Selecione Revisores necessários.
- Insira até até 6 pessoas ou equipes. Apenas um dos revisores precisam aprovar o trabalho para que prossiga.
- Opcionalmente, para impedir que os usuários aprovem as execuções de fluxos de trabalho que eles acionaram, selecione Impedir a auto-revisão.
- Clique em Salvar regras de proteção.
-
Opcionalmente, especifique o tempo a esperar antes de permitir que os trabalhos do fluxo de trabalho que usam esse ambiente prossigam. Para mais informações, confira "Temporizador de espera".
- Selecione Temporizador de espera.
- Insira o número de minutos para esperar.
- Clique em Salvar regras de proteção.
-
Opcionalmente, não permite ignorar regras de proteção configuradas. Para obter mais informações, confira "Permitir que os administradores ignorem as regras de proteção configuradas".
- Desmarque Permitir que os administradores ignorem as regras de proteção configuradas.
- Clique em Salvar regras de proteção.
-
Opcionalmente, habilite quaisquer regras personalizadas de proteção de implantação que tenham sido criadas com o GitHub Apps. Para obter mais informações, confira "Regras de proteção de implantação personalizadas".
- Selecione a regra de proteção personalizada que você deseja habilitar.
- Clique em Salvar regras de proteção.
-
Opcionalmente, especifique quais ramificações e marcas podem ser implantadas nesse ambiente. Para obter mais informações, consulte "Ramificações de implantação e marcas.
-
Selecione a opção desejada no menu suspenso Branches de implantação.
-
Se você escolher Ramificações selecionadas e marcas, para adicionar uma nova regra, clique em Adicionar regra de ramificação de implantação ou marca 1. No menu suspenso "Tipo de referência", dependendo da regra que você deseja aplicar, clique em Ramificação ou Marca .
-
Insira o padrão de nome para a ramificação ou marca que você deseja permitir.
Observação: os padrões de nomes devem ser configurados individualmente para ramificações ou marcas.
-
Clique em Adicionar regra.
-
-
Opcionalmente, adicione segredos de ambiente. Esses segredos só estão disponíveis para trabalhos de fluxo de trabalho que usam o ambiente. Além disso, os trabalhos do fluxo de trabalho que usam este ambiente só podem acessar esses segredos após todas as regras configuradas (por exemplo, revisores obrigatórios). Para obter mais informações, confira "Segredos do ambiente".
- Em Segredos do ambiente, clique em Adicionar Segredo.
- Insira o nome do segredo.
- Insira o valor do segredo.
- Clique em Adicionar segredo.
-
Opcionalmente, adicione variáveis de ambiente. Essas variáveis só ficam disponíveis para trabalhos de fluxo de trabalho que usam o ambiente e só podem ser acessadas usando o contexto
vars
. Para obter mais informações, confira "Variáveis de ambiente".- Em Variáveis de ambiente, clique em Adicionar Variável.
- Informe o nome da variável.
- Informe o valor da variável.
- Clique em Adicionar variável.
Também é possível criar e configurar ambientes por meio da API REST. Para obter mais informações, consulte "Pontos de extremidade da API REST para ambientes de implantação", "Pontos de extremidade da API REST para segredos do GitHub Actions", "Pontos de extremidade da API REST para variáveis do GitHub Actions" e "Pontos de extremidade da API REST para políticas de branch de implantação".
Executar um fluxo de trabalho que faz referência a um ambiente que não existe criará um ambiente com o nome referenciado. Se o ambiente for criado a partir da execução de compilações de página implícitas (por exemplo, de uma fonte de ramificação ou pasta), a ramificação fonte será adicionada como uma regra de proteção ao ambiente. Caso contrário, o novo ambiente criado não terá nenhuma regra de proteção ou segredo configurado. Qualquer pessoa que possa editar fluxos de trabalho no repositório pode criar ambientes por meio de um arquivo de fluxo de trabalho, mas apenas os administradores do repositório podem configurar o ambiente.
Excluir um ambiente
Para configurar um ambiente em um repositório de conta pessoal, você deve ser o proprietário do repositório. Para configurar um ambiente em um repositório da organização, você precisa ter acesso de admin
.
A exclusão de um ambiente apagará todos os segredos e regras de proteção associados ao ambiente. Todos os trabalhos que estejam atualmente em espera devido às regras de proteção do ambiente eliminado falharão automaticamente.
-
Em GitHub, acesse a página principal do repositório.
-
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.
-
Na barra lateral esquerda, clique em Ambientes.
-
Ao lado do ambiente que você deseja excluir, clique em .
-
Clique em Entendi. Excluir este ambiente.
Também é possível excluir ambientes por meio da API REST. Para obter mais informações, confira "Pontos de extremidade da API REST para repositórios".
Como os ambientes relacionam-se com as implantações
Quando um trabalho de fluxo de trabalho que referencia um ambiente é executado, ele cria um objeto de implantação com a propriedade environment
definida como o nome do ambiente. À medida que o fluxo de trabalho progride, ele também cria objetos de status de implantação com a propriedade environment
definida como o nome do ambiente, a propriedade environment_url
definida como a URL para o ambiente (se especificado no fluxo de trabalho) e a propriedade state
definida como o status do trabalho.
Você pode acessar esses objetos por meio da API REST ou API do GraphQL. Você também pode assinar esses eventos de webhook. Para obter mais informações, confira "Pontos de extremidade da API REST para repositórios," "Objetos" (API do GraphQL) ou "Eventos e cargas de webhook".
Próximas etapas
GitHub Actions fornece várias funcionalidades para gerenciar suas implantações. Para obter mais informações, confira "Implantando com GitHub Actions".