GitHub Codespaces es un entorno de desarrollo instantáneo basado en la nube que usa un contenedor para proporcionarle lenguajes comunes, herramientas y utilidades para el desarrollo. GitHub Codespaces también es configurable, lo que permite crear un entorno de desarrollo personalizado para el proyecto. Al configurar un ambiente de desarrollo personalizado para tu proyecto, puedes tener una configuración de codespace repetible para todos los usuarios de dicho proyecto.
Creando tu codespace
Hay varios puntos de entrada para crear un codespace.
- Desde una GitHub plantilla o cualquier repositorio de plantillas en GitHub para iniciar un nuevo proyecto
- Desde una rama del repositorio para el nuevo trabajo destacado
- Desde una solicitud de incorporación de cambios abierta para explorar el trabajo en curso
- Desde una confirmación en el historial de un repositorio para investigar un error en un punto específico del tiempo
Puede crear un codespace en GitHub, en Visual Studio Code o utilizando el GitHub CLI.
Tu codespace puede ser efímero si necesitas hacer pruebas en algo o puedes volver al mismo codespace para trabajar en características a largo plazo.
Para más información, consulta Creación de un codespace para un repositorio, Creación de un codespace a partir de una plantilla y Apertura de un codespace existente.
Nota:
Puedes crear más de un codespace por repositorio o incluso por rama. Sin embargo, hay límites para el número de codespaces que puede crear y el número de codespaces que puede ejecutar al mismo tiempo. Si alcanza el número máximo de codespaces e intenta crear otro, se muestra un mensaje que indica que debe quitar un codespace existente para poder crear uno nuevo.
Proceso de creación de un codespace
Al crear un codespace, se producen varios pasos en segundo plano antes de que el codespace esté disponible para ti.
Paso 1: Se asigna una MV y un almacenamiento a tu codespace
Al crear un espacio de código, se crea una máquina virtual (VM) mediante la versión estable o versión preliminar pública de lanzamiento de la imagen host de la VM. Para más información, consulta Elección de la imagen de host estable o beta. La imagen de host define la versión de Linux que se usa para la VM. La VM es tanto dedicada como privada para ti. El tener una MV dedicada garantiza que tengas un conjunto completo de recursos de cómputo disponibles para ti desde esa máquina. Si es necesario, esto también te permitirá tener acceso de raíz total a tu contenedor.
Entonces, se genera un clon superficial de tu repositorio, o del repositorio de plantilla si estás creando un codespace a partir de una plantilla. Este se clona en el /workspaces directorio de la VM y, posteriormente, se monta en el contenedor de desarrollador. Para obtener más información, consulta Acerca de la estructura de directorios de un codespace a continuación.
Paso 2: se crea el contenedor de desarrollador
GitHub Codespaces usa un contenedor de Docker como entorno de desarrollo. Este contenedor se crea en función de las configuraciones que puedes definir en un archivo devcontainer.json u, opcionalmente, en un Dockerfile. Si crea un espacio de código a partir de GitHubla plantilla en blanco o desde un repositorio sin devcontainer.json archivo, GitHub Codespaces usa una imagen predeterminada, que tiene muchos lenguajes y entornos de ejecución disponibles. Para más información, consulta Introducción a los contenedores dev. Para obtener detalles sobre lo que contiene la imagen predeterminada para contenedores de desarrollador, consulte el repositorio devcontainers/images.
Nota:
Si quieres usar enlaces de Git en el codespace y aplicar cualquier elemento del directorio de plantillas Git al codespace, tendrás que configurar enlaces durante el paso 4 después de crear el contenedor.
Como el repositorio se clona en la máquina virtual host antes de crear el contenedor, todo lo que se encuentra en el directorio de plantillas de Git no se aplicará en el codespace a menos que configure enlaces en el archivo de configuración devcontainer.json mediante postCreateCommand en el paso 4. Para más información, consulta Paso 4: Configuración posterior a la creación.
Paso 3: Conectarse al codespace
Cuando tu contenedor se crea y se ejecuta cualquier otra inicialización, estarás conectado a tu codespace. Puedes conectarse a él mediante lo siguiente:
- El explorador web
- Visual Studio Code
- GitHub CLI
Paso 4: Configuración post-creación
Una vez que te conectes al codespace, la configuración automatizada podría continuar la compilación en función de la configuración especificada en el archivo devcontainer.json. Es posible que vea que se ejecutan postCreateCommand y postAttachCommand.
Si quieres usar enlaces de Git en el codespace, configúralos mediante los devcontainer.jsonscripts de ciclo de vida, como postCreateCommand. Para obtener más información sobre los scripts de ciclo de vida, consulta la especificación de los contenedores de desarrollo en el sitio web de los contenedores de desarrollo.
Si tiene un repositorio de dotfiles público para GitHub Codespaces, puede habilitarlo para usarlo con nuevos codespaces. Cuando lo habilitas, tus dotfiles se clonarán en el contenedor y se invocará el script de instalación. Para más información, consulta Personalización de GitHub Codespaces para su cuenta.
Por último, si has creado el codespace desde un repositorio, todo el historial del repositorio se copiará con un clon integral. Si has creado el codespace a partir de una plantilla, no se conservará el historial completo del repositorio de plantilla. En su lugar, a menos que uses la plantilla en blanco, empezarás con una confirmación inicial para el contenido del repositorio de plantilla.
Durante la configuración post-creación, aún podrás utilizar la terminal integrada y editar tus archivos, pero ten cuidado de evitar cualquier condiciones de carrera entre tu trabajo y los comandos que se están ejecutando.
Codespaces ciclo de vida
Guardar archivos en tu codespace
Guarda los cambios en los archivos de la manera habitual, según el editor que estés usando.
Si trabaja en codespaces en Visual Studio Code, puede habilitar Auto Save para asegurarse de que los cambios siempre se guardan.
Cerrar o detener su codespace
El espacio de código seguirá ejecutándose mientras lo usa, hasta una duración máxima de 12 horas, pero agotará el tiempo de espera después de un período de inactividad. Los cambios de archivo del editor y de la salida del terminal se cuentan como actividad. Por lo tanto, no se agotará el tiempo de espera de tu codespace si la salida del terminal sigue. El período de tiempo de espera de inactividad predeterminado es de 30 minutos. Puedes definir una configuración de tiempo de espera personal para los Codespaces que crees, pero una directiva de tiempo de espera de la organización puede anularla. Para más información, consulta Configuración del periodo de tiempo de espera en tu GitHub Codespaces. Para obtener más información sobre la duración máxima, consulte Ciclo de vida de un codespace.
Si un espacio de código agota el tiempo de espera, dejará de ejecutarse, pero puede reiniciarlo desde la pestaña del explorador (si estaba usando el espacio de código en el explorador), desde dentro VS Codede o desde la lista de espacios de código en https://github.com/codespaces.
Para detener un codespace, puedes hacer lo siguiente:
- En el explorador: en tu lista de codespaces de https://github.com/codespaces, haz clic en los puntos suspensivos ( ... ) situados a la derecha del codespace que deseas detener y haz clic en Detener codespace.
- En VS Code: abra , Visual Studio Code Command Palette por ejemplo, presionando Ctrl+Mayús+P (Windows/Linux) o Mayús+Comando+P (Mac)
Codespaces: stopy presione Entrar. Para más información, consulta Uso de la paleta de comandos de Visual Studio Code en GitHub Codespaces. - En una ventana de terminal: use el GitHub CLI comando
gh codespace stop. Para más información, consulta Uso de GitHub Codespaces con la CLI de GitHub.
Si sales de tu codespace sin ejecutar el comando para detenerlo (por ejemplo, cerrando la pestaña del explorador) o si dejas el codespace ejecutándose sin interacción, este y sus procesos en ejecución seguirán durante el período de tiempo de espera de inactividad.
Cuando cierras o detienes tu codespace, todos los cambios sin confirmar se preservan hasta que te conectes al codespace nuevamente.
Ejecutar tu aplicación
La redirección de puertos te otorga acceso a los puertos TCP que funcionan dentro de tu codespace. Por ejemplo, si estás ejecutando una aplicación web por el puerto 4000 dentro de tu codespace, puedes reenviar ese puerto automáticamente para hacer la aplicación accesible desde tu buscador.
El reenvío de puertos determina cuáles de ellos se hicieron accesibles para ti desde la máquina remota. Incluso si no reenvías un puerto, este será accesible para otros procesos que se ejecuten dentro del mismo codespace.
Cuando una aplicación que se ejecuta dentro GitHub Codespaces de genera un puerto en la consola, GitHub Codespaces detecta el patrón de dirección URL de localhost y reenvía automáticamente el puerto. Puede hacer clic en la dirección URL del terminal o en el vínculo del mensaje de notificación "notificación del sistema" que aparece en la esquina inferior derecha de VS Code, para abrir el puerto en un explorador. De forma predeterminada, GitHub Codespaces reenvía el puerto mediante HTTP. Para obtener más información sobre el reenvío de puertos, consulta Reenviar puertos en tu codespace.
Si bien los puertos pueden reenviarse automáticamente, no son accesibles públicamente en la internet. Predeterminadamente, todos los puertos son privados, pero puedes poner a un puerto como disponible para tu organización o como público manualmente y luego compartir el acceso a través de una URL. Para más información, consulta Reenviar puertos en tu codespace.
El ejecutar tu aplicación cuando llegas por primera vez a tu codespace puede convertirse en un bucle de desarrollador interno rápido. Mientras editas, tus cambios se guardan automáticamente y se ponen disponibles en tu puerto reenviado. Para ver los cambios, regresa a la pestaña de la aplicación en ejecución en tu buscador y actualízala.
Confirmar y subir tus cambios
Git está instalado de manera predeterminada en tu codespace, por lo que puedes confiar en tu flujo de trabajo existente de Git. Puede trabajar con Git en el espacio de código, ya sea a través del terminal o mediante las características de control de código fuente de VS Code.
Si estás trabajando con un repositorio existente, puedes crear un codespace desde cualquier rama, confirmación o solicitud de incorporación de cambios en el repositorio o puedes cambiar a una rama existente o nueva desde dentro de tu codespace activo. Dado que GitHub Codespaces está diseñado para ser efímero, puede usarlo como entorno aislado para experimentar, comprobar la solicitud de incorporación de cambios de un compañero de equipo o corregir conflictos de combinación.
Si solo tienes acceso de lectura a un repositorio, puedes crear un codespace para el repositorio siempre que puedas bifurcarlo. Al realizar una confirmación desde el espacio de código o insertar una nueva rama, GitHub Codespaces crea automáticamente una bifurcación del repositorio o vincula el espacio de código a una bifurcación existente si ya tiene una para el repositorio ascendente.
Si estás trabajando en un codespace creado a partir de una plantilla, Git se instala de manera predeterminada, pero tendrás que publicar el codespace en un repositorio remoto para conservar el trabajo y compartirlo con otros usuarios. Si parte de la plantilla en blanco de GitHub, primero debe inicializar su espacio de trabajo como un repositorio Git (por ejemplo, escribiendo git init) para empezar a usar el control de versiones dentro del codespace.
Para más información, consulta Utilizar el control de código fuente en tu codespace.
Nota:
Las confirmaciones desde el codespace se atribuirán al nombre y al correo electrónico público configurados en https://github.com/settings/profile. Para la autenticación, se usará un token con ámbito en el repositorio, incluido en el entorno como GITHUB_TOKEN, y las credenciales de GitHub.
Personalizar tu codespace con extensiones
Puede agregar extensiones dentro de un espacio de código para personalizar la experiencia en VS Code.
VS Code extensiones
Si trabaja en los espacios de código de la VS Code aplicación de escritorio o en el cliente web, puede agregar las extensiones que necesite desde Visual Studio Code Marketplace. Para obtener información sobre cómo se ejecutan las extensiones en GitHub Codespaces, vea Compatibilidad con el desarrollo remoto y GitHub Codespaces en la VS Code documentación.
Si ya usa VS Code, puede usar La sincronización de configuración para sincronizar automáticamente extensiones, configuraciones, temas y métodos abreviados de teclado entre la instancia local y los espacios de código que cree.
Acerca de la estructura de directorios de un codespace
Al crear un codespace, el repositorio se clona en el directorio /workspaces del codespace. Es un directorio persistente que se monta en el contenedor. Todo cambio que se realice dentro de este directorio (incluida la edición, la adición o la eliminación de archivos) se conserva al detener e iniciar el codespace, así como al recompilar el contenedor en el codespace.
Fuera del directorio /workspaces, el codespace contiene una estructura de directorios de Linux que varía en función de la imagen de contenedor dev que se utiliza para compilar el codespace. Puede agregar archivos o realizar cambios en los archivos fuera del directorio /workspaces. Por ejemplo, puede instalar nuevos programas o puede establecer la configuración del shell en un archivo como ~/.bashrc. Como usuario no raíz, puede que no tengas acceso de escritura automáticamente a ciertos directorios, pero la mayoría de las imágenes permiten el acceso raíz a estos directorios con el comando sudo.
Fuera de /workspaces, a excepción del directorio /tmp, los directorios de un codespace están vinculados al ciclo de vida del contenedor. Esto significa que los cambios que se realicen se conservan al detener e iniciar el codespace, pero no al recompilar el contenedor. Para obtener más información sobre el /tmp directorio, consulte Persistencia de variables de entorno y archivos temporales.
Borrar los directorios fuera de /workspaces ayuda a asegurar que el contenedor recompilado esté en el mismo estado en el que estaría en un codespace recién creado. Si vas a volver a compilar un contenedor para aplicar cambios de configuración al codespace en el que estás trabajando, puedes estar seguro de que los cambios de configuración realizados funcionarán igual para los usuarios que creen nuevos codespaces con la misma configuración. Para más información, consulta Introducción a los contenedores dev.
Si deseas hacer cambios en tu espacio de código que sean más robustos durante las reconstrucciones y entre diferentes espacios de código, dispones de varias opciones.
- Para instalar programas y herramientas en todos los codespaces creados a partir de un repositorio, en la configuración del contenedor de desarrollo, puedes usar propiedades de comando de ciclo de vida, como
postCreateCommand, para ejecutar comandos de instalación personalizados, o puedes elegir entre comandos de instalación escritos previamente denominados "características". Para más información, consulta la especificación de contenedores de desarrollo en el sitio web Contenedores de desarrollo y Adición de características a un archivo devcontainer.json. - Para instalar herramientas o personalizar la configuración en cada espacio de código que cree, como configurar el
bashperfil, puede vincular GitHub Codespaces con un repositorio de dotfiles. El repositorio dotfiles también se clona en el directorio persistente/workspaces. Para más información, consulta Personalización de GitHub Codespaces para su cuenta. - Si deseas conservar archivos específicos sobre una recompilación, puede usar un archivo
devcontainer.jsonpara crear un enlace simbólico entre los archivos y un directorio persistente dentro de/workspaces. Para más información, consulta Reconstrucción del contenedor en un codespace.