Optimizar las peticiones de información

[Siotma]

Actualmente, el código realiza peticiones a la API de GitHub para recopilar todas las issues, incluso las que no tienen que ver con formación. En un futuro, si aumenta el número de operadores, el código será capaz de recopilar igualmente toda la información, pero el tiempo de ejecución crecerá de la misma manera.

Se me ocurren dos formas de optimizar:

• Recopilando únicamente las issues cerradas y con las etiquetas correctas, pero esto presenta un problema y es que el máximo de resultados que devuelve es 30 por lo que habría que habilitar paginación o algo parecido. (filtros state y label)

• Creando una caché local de las issues, y reopilando únicamente información de aquellas que han sido actualizadas desde el último backup para actualizar la información. (filtro updated)

[David-Estevez]

Soy más partidario de la opción 1, al menos mientras seamos nosotros los que pedimos información a GitHub en lugar de esperar a que nos mande él las updates.

El problema de paginación existía también en repostatistics, y fuimos capaces de resolverlo. Creo que unas peticiones más directas (con state y label), si se tiene en cuenta la paginación, reduciría mucho el número de peticiones a hacer.

[Siotma]

Se debe tener en cuenta que la información "closed_by" no está presente en un listado de issues del estilo https://api.github.com/repos/asrob-uc3m/operadores/issues?state=closed

Esta información únicamente está disponible si se hace una solicitud sobre una sola issue a la API como por ejemplo https://api.github.com/repos/asrob-uc3m/operadores/issues/4

Teniendo esto en cuenta, la optimización consistiría más bien en reducir el conjunto de issues que solicitar, y no sería tan sencillo como realizar una solicitud por página.

[David-Estevez]

Cierto, pero se ahorraría inspeccionar issues que de antemano sabemos que no están relacionadas con la formación de operadores (menos peticiones y tiempo de ejecución).

[Siotma]

Desde luego.
Se me ha ocurrido que una forma sencilla de realizar la paginación de issues es hacer peticiones utilizando el filtro created:YYYY-MM-DD.

El workflow sería:

1. Petición de las issues cerradas y correctamente etiquetadas más recientes.
2. Procesado de la información para extraer los números de issue.
3. La fecha de creación de la última issue recogida por la petición se almacena.
4. Petición de las issues cerradas y correctamente etiquetadas anteriores a la fecha del punto 3.
5. Si la API devuelve más issues, volver al punto 2; si no, pasar al punto 6.
6. Con los números de issue recogidos, realizar una petición por issue.

[David-Estevez]

Creo que la api del mismo GitHub tiene un sistema para ir pidiendo páginas, sin tener que calcular fechas. Investigaré a ver.