Rebuilding the container in a codespace

About rebuilding a container

When you work in a codespace, your development environment is a Docker container that runs on a virtual machine. If you make changes to your dev container configuration from within a codespace, and you want to apply those changes to the current codespace, you need to rebuild the container.

By default, when you rebuild a container, GitHub Codespaces will speed up the build process by reusing cached images from previous builds of the container. This is usually the quickest way to implement changes to your dev container configuration, for the following reasons.

GitHub Codespaces can reuse images in your cache rather than repulling them from container registries.
The parts of your dev container configuration that define how the container is built, such as dev container features and Dockerfile instructions, may have already been implemented in image layers in your cache, so you won't need to wait for these processes to run again. (However, commands in your configuration that run after the container is built, such as onCreateCommand, will run again.)

Occasionally, you may want to perform a full rebuild of your container. With a full rebuild, GitHub Codespaces cleans all Docker containers, images, and volumes from the cache, then rebuilds your container with newly pulled images. All the setup defined in your configuration will run again, generating new image layers. You may want to perform a full rebuild after many iterations of rebuilding your container with cached images, in situations such as the following.

You want to ensure that the setup defined in your configuration is not dependent on cached images, and will run as required when someone creates a new codespace based on the configuration. For example, a dependency may have been removed from the base image since it was last pulled into your codespace.
You want to free up the disk space used by your cache, for example if you are low on disk space or want to minimize storage charges. Your image cache might be using a significant amount of disk space if you've changed your base image multiple times, if you've made a large number of iterative changes to your configuration, or if you're running multiple containers with Docker Compose.

Rebuilding a container

You can rebuild a container within a codespace in the VS Code web client or desktop application, or you can use GitHub CLI.

Rebuilding the dev container in the VS Code web client or desktop application

Acesse o VS Code Command Palette com Shift+Comando+P (Mac) ou Ctrl+Shift+P (Windows/Linux).
Start typing "Rebuild" and select Codespaces: Rebuild Container or Codespaces: Full Rebuild Container.
Se as alterações na configuração do seu contêiner de desenvolvimento causarem um erro no contêiner, seu codespace será executado no modo de recuperação, e você verá uma mensagem de erro.
- Para diagnosticar o erro revisando os logs de criação, clique em Exibir log de criação.
- Para corrigir os erros identificados nos logs, atualize o arquivo devcontainer.json.
- Para aplicar as alterações, reconstrua seu contêiner.

Usando o GitHub CLI para recompilar um contêiner de desenvolvimento

Se você tiver alterado uma configuração de contêiner de desenvolvimento fora do VS Code (por exemplo, no GitHub.com ou em um IDE do JetBrains), use a GitHub CLI para recompilar o contêiner de desenvolvimento para um codespace existente.

Em um terminal, insira o comando a seguir.
```
gh codespace rebuild
```
Seus codespaces estão listados.
Use as teclas de direção no teclado para realçar o codespace necessário e pressione Enter.

To perform a full rebuild with GitHub CLI, you can use the gh codespace rebuild --full command.

Persisting data over a rebuild

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 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 sua configuração de shell em um arquivo como ~/.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.

If you want to preserve files outside the /workspaces directory over a rebuild, you can create, at the desired location in the container, a symbolic link (symlink) to the persistent directory. For example, in your /workspaces/.devcontainer directory, you can create a config directory that will be preserved across a rebuild. You can then symlink the config directory and its contents as a postCreateCommand in your devcontainer.json file.

{
    "image": "mcr.microsoft.com/vscode/devcontainers/base:alpine",
    "postCreateCommand": ".devcontainer/postCreate.sh"
}

In the example postCreate.sh file below, the contents of the config directory are symbolically linked to the home directory.

#!/bin/bash
ln -sf $PWD/.devcontainer/config $HOME/config && set +x