GitHub unifica las políticas de retención para ejecuciones de workflows, checks y estados

GitHub ha ampliado las políticas de retención de GitHub Actions para abarcar ejecuciones de workflows, checks y estados junto con artefactos y registros. Este cambio se aplica a los repositorios alojados en GitHub.com, introduciendo una gestión unificada del ciclo de vida para los registros de integración y entrega continuas creados tanto por trabajos de workflows nativos como por herramientas de terceros. Al alinear estos distintos tipos de metadatos bajo un mismo plazo de conservación, los administradores de repositorios obtienen un control más predecible sobre el historial de compilación y la huella del proyecto.

Configuración unificada de retención

Bajo la configuración actualizada, los registros de checks, ejecuciones de workflows y estados se eliminan automáticamente una vez que superan el umbral de retención establecido a nivel de repositorio, organización o empresa. En la interfaz de administración, esta opción consolidada se identifica bajo la etiqueta «Check, workflow run, status, artifact and log retention».

Antes de esta actualización, las políticas de retención regulaban principalmente el tiempo de conservación de artefactos de compilación y registros de ejecución, mientras que los metadatos de ejecución podían seguir reglas de expiración distintas. Ahora, todos los metadatos de ejecución asociados, las actualizaciones de estado y los resultados de checks individuales siguen exactamente el mismo cronograma de expiración, garantizando que los datos históricos del proyecto se limpien de forma sistemática.

Reglas de configuración y límites del sistema

Las opciones de retención a nivel de repositorio continúan sujetas a los límites máximos fijados por las políticas de la organización o empresa matriz. Los repositorios públicos aplican un límite máximo de retención de 90 días para todos los activos y registros vinculados a workflows. Por su parte, los entornos privados y empresariales pueden ajustar los plazos dentro de los márgenes administrativos permitidos según sus estrategias de cumplimiento.

GitHub ha señalado que ampliar la duración de una política de retención no restaurará de forma retroactiva los datos purgados tras ciclos anteriores. Por tanto, los equipos que necesiten auditar ejecuciones históricas o conservar registros durante periodos prolongados deben asegurarse de configurar los plazos correctamente antes de que se ejecuten las tareas automatizadas de mantenimiento.

Ilustración editorial generada con IA; no es una fotografía documental.

Fuente: Actions retention now covers checks, runs, and statuses