Resumen

  • Editar o eliminar una política de retención de Codespaces no modifica el plazo ya asignado a los espacios existentes. Las condiciones nuevas se aplican al crearlos.
  • Un espacio detenido sigue consumiendo almacenamiento. El borrado automático no espera a que sus cambios lleguen al repositorio remoto, de modo que reducir costes requiere organizar la salida del trabajo.

La empresa anuncia siete días de retención. Sus viejos Codespaces siguen con treinta. En ese ejemplo, el ahorro se ha aprobado en el menú, pero todavía no ha desalojado el almacenamiento.

El ejemplo de treinta a siete días es hipotético. La regla está en la documentación de GitHub: cada espacio recibe su retención al crearse. Cambiar la política de la organización no altera ese plazo; eliminar la política tampoco. Un menú actualizado puede describir perfectamente las próximas incorporaciones y decir muy poco sobre el inventario que sigue ocupando espacio.

La máquina parada tiene equipaje

El atractivo de un entorno de desarrollo remoto está, en parte, en poder volver. El programador detiene la máquina y más tarde recupera sus archivos guardados. Ese equipaje explica por qué apagar no equivale a desalojar.

Según el ciclo de vida de Codespaces, el consumo de cómputo corresponde al tiempo de ejecución; el almacenamiento continúa cuando el espacio está detenido y deja de acumularse al borrarlo. El borrado tampoco devuelve el uso ya acumulado durante el mes. Cerrar una pestaña del navegador, además, no detiene por sí solo la máquina remota.

Quien pretende ahorrar tiene que distinguir tres hechos que en una conversación rápida suelen mezclarse: cerrar la ventana, detener el entorno y eliminarlo. Cada uno deja un estado diferente. Ninguno obtiene sus efectos de la buena intención del usuario.

También importa quién paga. La política organizativa alcanza los espacios financiados por la organización. Un repositorio suyo puede dar lugar a un codespace pagado personalmente, fuera de ese alcance. Al crear un espacio se aplica el plazo más corto entre los límites pertinentes de organización, repositorio y preferencias personales. Para administrar la flota, la lista de repositorios necesita compañía: la identidad del pagador y el plazo realmente asignado.

Los documentos no incluyen el inventario, los plazos, los cambios pendientes ni la factura de una empresa concreta; hacen falta esos datos para calcular ahorros o pérdidas. Lo que sí permiten saber es por qué una nueva regla puede convivir con almacenamiento antiguo que todavía sigue consumiendo recursos.

El borrador se va con el escritorio

Un archivo guardado en el codespace sigue en la máquina virtual. Llevarlo al repositorio remoto requiere confirmar y enviar los cambios. La distancia entre ambos pasos puede contener una mañana de trabajo o una modificación pequeña que nadie recordará hasta que falte.

La política de borrado automático no concede una prórroga por tener cambios sin enviar. El vencimiento actúa igualmente. Esa es la parte incómoda de vender la retención más corta como una mejora gratuita: se reduce también el margen para sacar el trabajo que aún depende de ese entorno.

El valor predeterminado es borrar tras treinta días detenido e inactivo. Reconectarse reinicia el contador, que vuelve a correr después de detener el espacio. Las preferencias personales admiten de cero a treinta días; con cero, el borrado llega al detenerse, también cuando la detención se debe al tiempo de inactividad.

Por tanto, la antigüedad no ordena por sí sola la cola de salida. Un espacio viejo que se vuelve a utilizar puede seguir allí, mientras uno reciente con un plazo breve desaparece antes. Existe además una opción de conservación hasta el borrado manual para ciertos espacios personales, con su consumo de almacenamiento. Los espacios de la organización sometidos a una política de retención no disponen de esa excepción.

La mudanza tiene una puerta estrecha

GitHub ofrece exportar cambios a una rama sin arrancar el espacio. Es una salida útil cuando un límite de gasto impide abrirlo. La herramienta, sin embargo, exporta la rama actualmente seleccionada, no todas las ramas; los archivos de más de 100 MiB impiden la operación de envío correspondiente.

Conviene imaginar esa salida como una caja de mudanza con contenido comprobable. El equipo puede abrir la rama de destino, revisar qué llegó y tratar por separado lo que quedaba en otras ramas. También tiene que saber cómo reconstruir el entorno. Exportar código y conservar una estación de trabajo completa son compras distintas.

El recorte eficaz empieza entonces por una pregunta menos vistosa que «¿cuántos días ponemos?»: ¿qué espacios concretos podemos cerrar después de recuperar lo que importa? La nueva política ordena la entrada. La respuesta a esa pregunta libera el almacén.