Note
No momento, não há suporte para executores hospedados no GitHub no GitHub Enterprise Server. Você pode ver mais informações sobre o suporte futuro planejado no GitHub public roadmap.
About secrets
Secrets allow you to store sensitive information in your organization, repository, or repository environments. Secrets are variables that you create to use in GitHub Actions workflows in an organization, repository, or repository environment.
GitHub Actions can only read a secret if you explicitly include the secret in a workflow.
Naming your secrets
Tip
To help ensure that GitHub redacts your secrets in logs correctly, avoid using structured data as the values of secrets.
The following rules apply to secret names:
- 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.
Se houver um segredo com o mesmo nome em vários níveis, o segredo no nível mais baixo terá precedência. Por exemplo, se um segredo a nível de organização tiver o mesmo nome que um segredo a nível de repositório, o segredo a nível de repositório terá prioridade. Similarly, if an organization, repository, and environment all have a secret with the same name, the environment-level secret takes precedence.
Using your secrets in workflows
Warning
Se um segredo foi usado no trabalho, o GitHub edita automaticamente os segredos impressos no log. Você deve evitar imprimir segredos no log intencionalmente.
Para segredos armazenados no nível da organização, é possível usar políticas de acesso para controlar quais repositórios podem usar segredos da organização. Segredos no nível da organização permitem que você compartilhe segredos entre vários repositórios, o que reduz a necessidade de criar segredos duplicados. A atualização de um segredo de organização em um único local também garante que a alteração tenha efeito em todos os fluxos de trabalho do repositório que usam esse segredo.
For environment secrets, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.
To make a secret available to an action, you must set the secret as an input or environment variable in your workflow file. Review the action's README file to learn about which inputs and environment variables the action expects. See Sintaxe de fluxo de trabalho para o GitHub Actions.
Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job referencing the environment starts.
Limiting credential permissions
When generating credentials, we recommend that you grant the minimum permissions possible. For example, instead of using personal credentials, use deploy keys or a service account. Consider granting read-only permissions if that's all that is needed, and limit access as much as possible.
When generating a personal access token (classic), select the fewest scopes necessary. When generating a fine-grained personal access token, select the minimum permissions and repository access required.
Instead of using a personal access token, consider using a GitHub App, which uses fine-grained permissions and short lived tokens, similar to a fine-grained personal access token. Unlike a personal access token, a GitHub App is not tied to a user, so the workflow will continue to work even if the user who installed the app leaves your organization. For more information, see Fazer solicitações de API autenticadas com um Aplicativo do GitHub em um fluxo de trabalho do GitHub Actions.