Mejora en la Sincronización de Actividad de GitHub en devlog-ist/landing

El Problema

En el proyecto devlog-ist/landing, necesitábamos una forma más robusta y escalable de sincronizar la actividad de GitHub. El método anterior, basado en SyncGitHubActivityJob, estaba limitado a aproximadamente 90 días de historial debido a las restricciones de la API de eventos de GitHub. Esto significaba que no podíamos acceder al historial completo de commits y pull requests de los repositorios, lo cual era crucial para ofrecer una visión completa de la actividad de desarrollo.

La Solución

Decidimos reemplazar la sincronización completa con un enfoque por repositorio, utilizando SyncOwnedRepoActivityJob. Este nuevo método utiliza las APIs de Commits y Pulls de GitHub, que no tienen límite de tiempo, permitiéndonos acceder al historial completo. Esto implicó varios cambios clave:

• Eliminación de la acción full_github_resync del panel de control.
• Eliminación del método executeFullGitHubResync() del trait SyncsGitHubActivity.
• Reescritura del comando FullGitHubResyncCommand para distribuir trabajos por repositorio.
• Actualización de las pruebas para reflejar el nuevo comportamiento.
• Eliminación de las claves de traducción asociadas a la acción eliminada.

Este cambio permite una sincronización más completa y precisa del historial de actividad de GitHub.

Detalles Técnicos

El cambio principal reside en la transición de un proceso único y masivo a una serie de procesos más pequeños y manejables. Antes, un solo job intentaba sincronizar toda la actividad, lo cual era ineficiente y estaba limitado por la API. Ahora, el comando FullGitHubResyncCommand actúa como un orquestador, creando y despachando jobs individuales para cada repositorio.

Este es un ejemplo simplificado de cómo se despachan los jobs:

foreach ($repositorios as $repositorio) {
    dispatch(new SyncOwnedRepoActivityJob($repositorio));
}

Este enfoque batch permite una mayor flexibilidad y escalabilidad, ya que cada job puede ser procesado de forma independiente y en paralelo.

Beneficios

• Historial Completo: Acceso al historial completo de commits y pull requests sin la limitación de los 90 días.
• Escalabilidad: Mayor capacidad para manejar un gran número de repositorios y un gran volumen de actividad.
• Robustez: Mayor tolerancia a fallos, ya que un fallo en la sincronización de un repositorio no afecta a los demás.

Conclusión

La transición a un enfoque de sincronización por repositorio ha mejorado significativamente la capacidad de devlog-ist/landing para ofrecer una visión completa y precisa de la actividad de desarrollo en GitHub. Este cambio no solo ha resuelto las limitaciones del método anterior, sino que también ha sentado las bases para futuras mejoras en la gestión y el análisis de datos de GitHub.