Using environments for deployment

You can configure environments with protection rules and secrets. A workflow job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.

Environments, environment protection rules, and environment secrets are available in public repositories for all products. For access to environments in private repositories, you must use GitHub Enterprise.

About environments

Environments are used to describe a general deployment target like production, staging, or development. When a GitHub Actions workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see "Viewing deployment history."

You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the environment protection rules pass.

Environment protection rules

Environment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use environment protection rules to require a manual approval or delay a job.

Required reviewers

Use required reviewers to require a specific person or team to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewers must have at least read access to the repository. Only one of the required reviewers needs to approve the job for it to proceed.

For more information on reviewing jobs that reference an environment with required reviewers, see "Reviewing deployments."

Wait timer

Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 0 and 43,200 (30 days).

Environment secrets

Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see "Encrypted secrets."

Note: Workflows that run on self-hosted runners are not run in an isolated container, even if they use environments. Environment secrets should be treated with the same level of security as repository and organization secrets. For more information, see "Security hardening for GitHub Actions."

Creating an environment

Para configurar um ambiente em um repositório de conta de usuário, você deve ser o proprietário do repositório. Para configurar um ambiente em um repositório da organização, é necessário ter acesso de administrador.

  1. No your GitHub Enterprise Server instance, navegue até a página principal do repositório.
  2. No nome do seu repositório, clique em Configurações. Botão de configurações do repositório
  3. Na barra lateral esquerda, clique em Ambientes.
  4. Clique em Novo ambiente.
  5. 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.
  6. Optionally, specify people or teams that must approve workflow jobs that use this environment.
    1. Select Required reviewers.
    2. Enter up to 6 people or teams. Only one of the required reviewers needs to approve the job for it to proceed.
    3. Click Save protection rules.
  7. Optionally, specify the amount of time to wait before allowing workflow jobs that use this environment to proceed.
    1. Select Wait timer.
    2. Enter the number of minutes to wait.
    3. Click Save protection rules.
  8. Optionally, specify what branches can deploy to this environment. For more information about the possible values, see "Deployment branches."
    1. Select the desired option in the Deployment branches dropdown.
    2. If you chose Selected branches, enter the branch name patterns that you want to allow.
  9. Optionally, add environment secrets. These secrets are only available to workflow jobs that use the environment. Additionally, workflow jobs that use this environment can only access these secrets after any configured rules (for example, required reviewers) pass. For more information about secrets, see "Encrypted secrets."
    1. Under Environment secrets, click Add Secret.
    2. Enter the secret name.
    3. Enter the secret value.
    4. Click Add secret.

Running a workflow that references an environment that does not exist will create an environment with the referenced name. The newly created environment will not have any protection rules or secrets configured. Anyone that can edit workflows in the repository can create environments via a workflow file, but only repository admins can configure the environment.

Using an environment

Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. The job can access the environment's secrets only after the job is sent to a runner.

When a workflow references an environment, the environment will appear in the repository's deployments. For more information about viewing current and previous deployments, see "Viewing deployment history."

Você pode especificar um ambiente para cada tarefa do seu fluxo de trabalho. Para fazer isso, adicione um chave a função .<job_id>.environment seguida pelo nome do ambiente.

Por exemplo, esse fluxo de trabalho usará um ambiente denominado produção.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

When the above workflow runs, the deployment job will be subject to any rules configured for the production environment. For example, if the environment requires reviewers, the job will pause until one of the reviewers approves the job.

You can also specify a URL for the environment. The specified URL will appear on the deployments page for the repository (accessed by clicking Environments on the home page of your repository) and in the visualization graph for the workflow run. If a pull request triggered the workflow, the URL is also displayed as a View deployment button in the pull request timeline.

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: 
      name: production
      url: https://github.com
    steps:
      - name: deploy
        # ...deployment-specific steps

Workflow graph with URL

Deleting an environment

Para configurar um ambiente em um repositório de conta de usuário, você deve ser o proprietário do repositório. Para configurar um ambiente em um repositório da organização, é necessário ter acesso de administrador.

Deleting an environment will delete all secrets and protection rules associated with the environment. Any jobs currently waiting because of protection rules from the deleted environment will automatically fail.

  1. No your GitHub Enterprise Server instance, navegue até a página principal do repositório.
  2. No nome do seu repositório, clique em Configurações. Botão de configurações do repositório
  3. Na barra lateral esquerda, clique em Ambientes.
  4. Next to the environment that you want to delete, click .
  5. Click I understand, delete this environment.

How environments relate to deployments

Quando um trabalho de fluxo de trabalho faz referência a execuções de um ambiente, ele cria um objeto de implantação com a propriedade ambiente definida para o nome do seu ambiente. À medida que o fluxo de trabalho avança, ele também cria objetos de estado de implantação com a propriedade ambiente definida para o nome do seu ambiente. A propriedade environment_url definida como URL para o ambiente (se especificado no fluxo de trabalho), e a propriedade estado definida como estado do trabalho.

You can access these objects through the REST API or GraphQL API. You can also subscribe to these webhook events. For more information, see "Repositories" (REST API), "Objects" (GraphQL API), or "Webhook events and payloads."

Next steps

GitHub Actions provides several features for managing your deployments. For more information, see "Deploying with GitHub Actions."

Esse documento ajudou você?

Política de Privacidade

Ajude-nos a tornar esses documentos ótimos!

Todos os documentos do GitHub são de código aberto. Você percebeu que algo que está errado ou não está claro? Envie um pull request.

Faça uma contribuição

Ou, aprenda como contribuir.