Resumo

  • Alterar ou excluir a política de retenção de uma organização não muda o prazo dos codespaces existentes. Cada ambiente recebe seu prazo quando é criado.
  • O armazenamento continua sendo consumido depois da parada. A exclusão automática ocorre mesmo com alterações que ainda não foram enviadas ao repositório remoto.

O corte de despesas pode ficar pronto no painel antes de chegar à infraestrutura. Uma organização troca trinta dias de retenção por sete, leva a tela para a reunião e descobre depois que os ambientes antigos continuam ocupando lugar. Na GitHub, há uma explicação perfeitamente documentada para esse desencontro.

O exemplo de trinta para sete dias é hipotético. A regra do Codespaces atribui o prazo quando o ambiente nasce. Editar a política da organização não altera o prazo já recebido. Excluir a política também não. A mudança disciplina as novas entradas, enquanto o estoque anterior continua com suas próprias condições.

É uma pequena aula sobre o que uma configuração consegue governar. A empresa mudou a regra de admissão. Ainda precisa resolver o destino de quem já está lá dentro.

A conveniência ocupa espaço

Um ambiente remoto permite parar e voltar ao trabalho com os arquivos salvos. A equipe compra tempo de retomada: menos trabalho para reconstruir a bancada antes de produzir. A documentação do ciclo de vida mostra a contrapartida. O uso de computação ocorre enquanto o codespace está em execução; o de armazenamento continua quando ele está parado e só deixa de acumular com a exclusão.

Excluir também não apaga o consumo já acumulado no mês. A economia futura exige que o recurso deixe de existir; a conta passada conserva a memória do uso. Fechar a aba do navegador nem sequer garante a parada do ambiente remoto.

A política da organização tem ainda um limite financeiro: ela alcança os codespaces pagos pela organização. Um ambiente criado a partir de seu repositório, mas pago pessoalmente, não entra nesse regime só por causa da origem do código. Na criação, prevalece o menor prazo entre as restrições aplicáveis de organização, repositório e preferências pessoais.

Uma lista de repositórios, portanto, não basta para prever a despesa que a política pode afetar. É preciso identificar quem paga cada ambiente e qual prazo ele recebeu. A documentação pública não traz o inventário, os prazos, as alterações pendentes ou a fatura de um cliente; são esses dados que permitiriam calcular sua economia ou sua perda.

A conclusão operacional já cabe no que está publicado: olhar apenas a regra atual pode esconder várias safras de ambientes sob condições diferentes. Um prazo curto na entrada não realiza sozinho o trabalho de retirar o estoque.

O botão de salvar deixa uma tarefa pendente

Salvar arquivos na máquina virtual é uma etapa. Fazer commit e enviar as alterações ao repositório remoto é outra. Entre elas pode existir trabalho que a equipe considera pronto, mas que continua dependendo da sobrevivência daquele ambiente.

A exclusão automática acontece mesmo quando há alterações ainda não enviadas. O calendário não confere o valor do que ficou na gaveta. Ao escolher um prazo menor, a empresa também encurta o tempo disponível para organizar essa saída nos ambientes que receberem a nova condição.

Por padrão, um codespace parado e inativo é excluído depois de trinta dias. Uma nova conexão reinicia o contador, que volta a correr após a parada. A preferência pessoal pode ser definida entre zero e trinta dias. Zero significa exclusão ao parar, inclusive quando a parada resulta do limite de inatividade.

Isso embaralha uma intuição comum: o ambiente mais antigo não é necessariamente o primeiro a sair. Ele pode continuar sendo acessado e renovar sua contagem, enquanto um recém-criado recebe prazo mais curto. Alguns ambientes pessoais podem ser mantidos até a exclusão manual, com o armazenamento correspondente; essa opção não está disponível para ambientes da organização sujeitos à sua política de retenção.

A idade do ambiente, o prazo que ele recebeu e sua última utilização são informações diferentes. A faxina precisa das três.

Conferir o que saiu pela porta

Há uma forma de exportar alterações para uma branch sem iniciar o codespace. Ela pode ajudar quando um limite de gastos impede a reabertura. Mas a exportação cobre somente a branch atualmente selecionada. Outras branches ficam fora, e arquivos maiores que 100 MiB impedem a operação de envio correspondente.

Esse limite dá conteúdo à palavra “recuperado”. A equipe deve conseguir abrir a branch de destino e encontrar ali as alterações necessárias. Também precisa decidir o que fazer com trabalho existente em outras branches e saber como reconstruir o ambiente. Uma branch exportada entrega código dentro de um escopo; a bancada inteira tem mais peças.

A economia fica mais convincente quando segue essa ordem: localizar o ambiente, recuperar o trabalho, avaliar a conveniência de mantê-lo pronto e executar a decisão. A política nova evita repetir certas escolhas nos próximos ambientes. O dinheiro e a capacidade presos nos antigos exigem uma visita ao estoque.