Como definir variáveis de ambiente persistentes
Você pode definir variáveis de ambiente personalizadas persistentes de várias maneiras, dependendo de quais codespaces, repositórios ou usuários aos quais deseja disponibilizar as variáveis.
Para todos os métodos de configuração de variáveis personalizadas listados abaixo, você pode acessar a variável personalizada em seu codespace usando uma sintaxe como echo $VARNAME.
Para um só codespace
Você pode definir o valor da variável de ambiente no arquivo ~/.bashrc, ou em um arquivo de configuração equivalente se não estiver usando o shell do Bash. Por exemplo, adicione a instrução VARNAME=value.
Depois de salvar a alteração nesse arquivo, o valor será definido da próxima vez que você abrir o codespace ou você poderá defini-lo imediatamente usando um comando como source ~/.bashrc. A variável permanecerá definida se você parar e iniciar o codespace. No entanto, as alterações nos arquivos do diretório base serão redefinidas se você recompilar o contêiner, para que as variáveis definidas no arquivo ~/.bashrc não persistam em uma recompilação. Para obter mais informações, confira "Como impedir que arquivos temporários sejam excluídos automaticamente".
Para todos os codespaces de um repositório
Há três maneiras de definir variáveis de ambiente personalizadas persistentes para todos os codespaces criados para um repositório:
- Você pode editar o arquivo de configuração
devcontainer.jsondo repositório. - Você pode usar um Dockerfile personalizado.
- É possível usar segredos do ambiente de desenvolvimento.
Editar o arquivo de configuração devcontainer.json do repositório
Edite o arquivo de configuração devcontainer.json do repositório e use a propriedade remoteEnv para definir o valor da variável de ambiente:
{
"remoteEnv": {
"VARNAME": "value"
}
}
Use esse método apenas para valores que você está feliz em fazer commit em seu repositório como texto não criptografado. Para valores confidenciais, como tokens de acesso, use segredos do ambiente de desenvolvimento.
A variável de ambiente será definida dentro do processo de servidor remoto do editor e estará disponível para subprocessos do processo desse servidor remoto, como terminais e sessões de depuração. No entanto, a variável não estará disponível mais amplamente dentro do contêiner. Esse método será útil se você não precisar que a variável de ambiente seja definida para outros processos em segundo plano executados na inicialização e se você estiver usando uma imagem predefinida e não tiver ou quiser um Dockerfile personalizado.
Essa configuração vai entrar em vigor quando você recompilar o contêiner ou criar um codespace depois de enviar essa alteração por push para o repositório. Para obter mais informações sobre como aplicar alterações de configuração a um codespace, confira "Introdução aos contêineres de desenvolvimento".
Usar um Dockerfile personalizado
Se você estiver usando um Dockerfile personalizado, poderá definir a variável de ambiente lá adicionando ENV VARNAME=value.
Esse método será útil se você já tiver um Dockerfile e quiser definir uma variável no âmbito do contêiner.
Essa configuração vai entrar em vigor quando você recompilar o contêiner ou criar um codespace depois de enviar essa alteração por push para o repositório. Para obter mais informações sobre como aplicar alterações de configuração a um codespace, confira "Introdução aos contêineres de desenvolvimento".
Usar segredos do ambiente de desenvolvimento
Você pode usar segredos do ambiente de desenvolvimento para o GitHub Codespaces a fim de definir variáveis personalizadas para codespaces criados para o repositório. Para obter mais informações, confira "Gerenciando segredos específicos da sua conta para o GitHub Codespaces".
Você deve usar esse método para valores de variáveis de ambiente que não deseja fazer commit no repositório como texto não criptografado.
Essa configuração vai entrar em vigor na próxima vez que você criar um codespace para esse repositório ou quando reiniciar um codespace existente.
Para todos os codespaces que você criar
Se você quiser definir uma variável de ambiente personalizada para todos os codespaces que criar, poderá defini-la usando um arquivo no repositório dotfiles. Por exemplo, adicione VARNAME=value ao arquivo .bash_profile. As variáveis de ambiente definidas em um dotfile são específicas para você e não são atribuídas a ninguém mais. Para obter mais informações sobre Dotfiles, confira "Como personalizar o GitHub Codespaces para sua conta".
Como impedir que arquivos temporários sejam excluídos automaticamente
Quando você cria um codespace, seu repositório é clonado no diretório /workspaces no seu codespace. Esse é um diretório persistente que é montado no contêiner. Todas as alterações feitas dentro desse diretório, incluindo edição, adição ou exclusão de arquivos, são preservadas quando você para e inicia o codespace e recompila o contêiner no codespace.
Fora do diretório /workspaces, o codespace contém uma estrutura de diretório do Linux que varia conforme a imagem de contêiner de desenvolvimento usada para criar o codespace. Você pode adicionar arquivos ou fazer alterações em arquivos fora do diretório /workspaces. Por exemplo, você pode instalar novos programas ou definir a configuração do shell em um arquivo como o ~/.bashrc. Como um usuário não raiz, talvez você não tenha acesso de gravação automaticamente em alguns diretórios, mas a maioria das imagens permite o acesso raiz a esses diretórios com o comando sudo.
Fora de /workspaces, com exceção do diretório /tmp, os diretórios em um codespace são vinculados ao ciclo de vida do contêiner. Isso significa que todas as alterações feitas são preservadas quando você para e inicia o codespace, mas não são preservadas quando você recompila o contêiner. Para obter informações sobre como criar links simbólicos para preservar dados fora do diretório /workspaces, confira "Como recompilar o contêiner em um codespace".
O diretório /tmp é uma exceção porque está montado no contêiner, mas não é persistente. Portanto, o conteúdo do diretório /tmp é persistente em uma recompilação, mas é limpo sempre que o codespace é interrompido. Por exemplo, o diretório /tmp é limpo quando uma sessão de codespace atinge o tempo limite após um período de inatividade. Para obter mais informações, confira "Como definir seu período de tempo limite para o GitHub Codespaces".
Se você tiver arquivos temporários que deseja que estejam disponíveis da próxima vez que iniciar o codespace, não os salve no diretório /tmp.