Acelera las ejecuciones en CI #2702
Conversation
|
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 |
rtobar
force-pushed
the
faster-ci
branch
6 times, most recently
from
6db80ea to
ea578de
Compare
Hacerlo por nuestra cuenta no trae ningún beneficio, ya que actions/checkout ya usa --depth=1 (además de otras opciones).
Esto nos permitirá ver mejor en qué pasó en particular nos estamos demorando más.
rtobar
force-pushed
the
faster-ci
branch
5 times, most recently
from
38985b3 to
b2f46b8
Compare
Todos los pasos estaban antes aglomerados. Ya que queremos agregar más pasos, es beneficioso agrupar los pasos existentes para clarificar qué lógica se está llevando a cabo. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
Esto se logra deshabilitando algunos triggers (nostros nos encargamos de postgresql-common) y corriendo con ciertas opciones, como deshabilitando fsyncs
Para los paquetes que usamos no es necesario realizar esta operación, con lo cual nos ahorramos un poco de tiempo.
Al instalar locales-all se evita la generación de los locales en español al momento de instalar language-pack-es. Esta generación de locales toma un tiempo considerable de CPU, por lo que instalar locales-all es finalmente menos costoso.
El job Test del workflow Test corre durante pull requests y durante pushes al branch principal del repositorio. En el primer caso, los PRs contienen normalmente un solo archivo .po que ha cambido, pero aún así los chequeos que se corren en CI se hacen contra todos los archivos .po, lo cual es ineficiente. En particular, pospell toma alrededor de un minuto y medio en correr, cuando tomaría alrededor de un segundo en correr sobre un solo archivo. Este commit introduce una serie de pasos en el job Test que calcula la lista de archivos .po sobre los cuales se correrán el resto de los chequeos. Cuando el trabajo corre como parte de un PR, sólo los archivos .po que han cambiado en el PR (si es que los hay) son incluidos. Cuando el trabajo corre como parte de un push a la rama principal del repositorio, todos los archivos son incluidos. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
Mírese el commit anterior para más detalles. Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>
|
No conocía esos actions para optimizar el uso de 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, |
|
@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).
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.
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? |
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. |
Co-authored-by: Cristián Maureira-Fredes <cmaureir@users.noreply.github.com>
|
@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. |
Este PR modifica el job
Testdel workflowTest(i.e., el pipeline que se corre en cada PR y push a 3.12) con los siguientes cambios:actions/checkout(no hay beneficio en hacerlo por cuentra propia)locales-allpara evitar la generación de los locales en español, ya que esta generación consume un largo tiempo de CPU, mientras que bajar el paquete es mucho más rápido. También se evita correrapt update.