Ah, entonces instalamos las cosas a nivel de configuración de la máquina, pero no cuando la comenzamos ¿verdad?

Ah, entonces instalamos las cosas a nivel de configuración de la máquina, pero no cuando la comenzamos ¿verdad?

Eso pensaba hacer, pero la verdad es que no es tan simple. La único opción de tener un sistema pre-configurado es usar imágenes Docker y correr todo dentro de un container en vez de directo en "ubuntu-22.04" (aunque probablemente ese ya sea un container...), y aún no he explorado esa opción. Lo que si probé acá, y que parece dsr algo de mejoría, es configurar apt y dpkg para saltarse algunos pasos (e.g., no generar páginas de.manual, no usar fsync, etc). Pero lejos el paso de setup que de demora más es la generación de los locales en español. Me gustaría explorar el tratar de cachear eso de alguna forma, actualmente ese paso demora cerca de un minuto.

Ooops, botón equivocado...

La verdad es que tampoco he tenido mucho tiempo de hacer nada muy serio que requiera sentarse en un computador (he estado desde el celular todos estos días), pero cuando encuentre un tiempito me gustaría dedicarle una horita a seguir explorando estás posibilidades

No conocía esos actions para optimizar el uso deubuntu-latest, me parece muy bien 🔥

Lo único que no estoy seguro es la parte de détección de archivos po modificados. Me parece que eso es algo que puede ser útil tener localmente y sería mejor integrarlo en los scripts. Por ejemplo,powrap ya tiene una opción--modified para correr sólo sobre los arcihvos modificados. De la misma forma podríamos tener algo así en elcheck_spell.py.
De hecho creo que esto es exactamente lo que hacepre-commit: corre localmente y ejecuta los checks sólo sobre los archivos modificados.

@mmmarcos gracias por los comentarios!

Respecto a tener una lógica común que se puede reusar en todos los scripts: ésto no es tan fácil, porque lo que se busca tener es una lista de los archivos que han sido modificados en el PR con respecto a la rama base. Esa información es posbile obtenerla sólo si estás al tanto de la existencia del PR en primer lugar, por lo que no sería algo que se podría hacer de manera local (de forma fácil... con suficiente complejidad sí se puede armar algo así teoréticamente).

Por ejemplo,powrap ya tiene una opción--modified para correr sólo sobre los arcihvos modificados

Efectivamente, pero esa opción corre sólo sobre los archivos modificados localmente:https://github.com/AFPy/powrap/blob/03a472d4823a9d68af68c4575a93c572c4152165/powrap/powrap.py#L159. Esto es diferente a lo que se necesita para evaluar PRs, donde queremos la lista de archivos que se ha modificado en el PR respecto a la rama base.

[...] De hecho creo que esto es exactamente lo que hacepre-commit: corre localmente y ejecuta los checks sólo sobre los archivos modificados.

Si mal no entiendo, pre-commit por defecto detecta los archivos que están incluidos en el commit que se está creando en ese momento, y todos los hooks se corren sobre ellos, si corresponde. Así que, de nuevo, es una semántica diferente a la que se necesita para los PRs.

Gracias por la explicación@rtobar ahora veo mejor la diferencia :)

Tenés una idea de cuanto tiempo se puede ganar? O hay que mergear la PR primero para ver?
Igual, me parece bien de mergear 👍

Tenés una idea de cuanto tiempo se puede ganar?

Con estos cambios estamos cortando al menos unos dos minutos de ejecución, que de dividen más o menos en 1.5 minutos de pospell que ahora son alrededor de un segundo más/menos, y otro minuto en tiempo de instalación de paquetes de sistema.

@cmaureir si estás feliz con los cambios podrías aprobar y mergear? Gracias! Serio bueno empezar a ver estos cambios andando en el resto de los PRs.