Libseccomp: ERROR: busque reemplazar Travis CI con acciones de GitHub

Aquí hay una guía para migrar de TravisCI a Github Actions. Espero experimentar con esto en los próximos días.
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions / migrating-from-travis-ci-to-github-actions

Realmente me gusta el aspecto de Github Actions. Acabo de enviar un conjunto de parches para cambiar libcgroup de Travis CI a Github Actions.

https://github.com/drakenclimber/libcgroup/tree/issues/github_actions
https://sourceforge.net/p/libcg/mailman/message/37165461/

Intentaré armar un conjunto de parches para la transición de libseccomp esta semana.

Eso suena bien @drakenclimber , ¡gracias!

Aquí está mi estado actual. Tengo acciones de Github trabajando en amd64 con algunas desviaciones leves de nuestra solución actual de Travis CI, pero me preocupan otras arquitecturas.

Pros:

• Fácil de usar. Pude configurar rápidamente un flujo de
• También es fácil encapsular las operaciones en una acción . Luego, estas acciones se pueden reutilizar dentro del flujo de trabajo. (Curiosamente, una acción no puede invocar otra acción ).
• Velocidad aceptable (para amd64 al menos). Todo el conjunto de pruebas se completó en 22 minutos
• La buena GUI y los pasos fallidos están claramente delineados
• Realmente me gustan las opciones de paralelización de Github Actions, y proporciona una función para recopilar resultados una vez que se completan otros trabajos. Estoy usando esta función en libcgroup para finalizar sus números de cobertura de código después de que se hayan ejecutado todas las pruebas

Contras:

• Sin soporte nativo para otras arquitecturas
  
  
  
  • Un empleado de github proporcionó esta solución para ejecutar un contenedor de Docker arm64. Lo probé, y con algunos retoques pude hacer que el conjunto de pruebas básico funcionara en su mayor parte. (La prueba 52 - carga básica - falló por alguna extraña razón). Pero esta configuración es difícil de reproducir localmente y la depuración es un desafío significativo. No pude hacer funcionar las pruebas de Python. Ah, y es muy, muy lento: tomó una hora ejecutar un conjunto reducido de pruebas en arm64. ppc64el tomó 6 horas antes de que lo matara :(
  
  
  • Un usuario de github creó esta acción que también usa contenedores Docker para ejecutar arquitecturas no nativas. La sintaxis es algo torpe y nos obligaría a duplicar el código. Su arquitectura compatible
  
  
  • Github Actions admite el uso de corredores autohospedados, por lo que una opción (fea) sería encontrar un cuadro arm64, ppc64le, etc. dedicado y usarlo para ejecutar las pruebas. La ventaja de esto es que la depuración sería mucho más sencilla que un contenedor Docker.
  
  

Otro:

• Coveralls.io ha creado una acción de Github . Nuestra solución TravisCI existente, cpp-coveralls , funciona en Github Actions, pero tuvo problemas con las compilaciones paralelas. Tengo la acción de Coveralls trabajando en paralelo en libcgroup
• Para utilizar la acción de Coveralls , tuve que esta línea estaba cubierta o no, mientras que la solución Github Actions la llama explícitamente
• Nota personal: no tengo el indicador --exclude src/arch-syscall-check.c lcov funcionando. No tengo ni idea de por qué

Aquí está mi estado actual. Tengo acciones de Github trabajando en amd64 con algunas desviaciones leves de nuestra solución actual de Travis CI, pero me preocupan otras arquitecturas.

Pros:

• Fácil de usar. Pude configurar rápidamente un flujo de
• También es fácil encapsular las operaciones en una acción . Luego, estas acciones se pueden reutilizar dentro del flujo de trabajo. (Curiosamente, una acción no puede invocar otra acción ).
• Velocidad aceptable (para amd64 al menos). Todo el conjunto de pruebas se completó en 22 minutos
• La buena GUI y los pasos fallidos están claramente delineados
• Realmente me gustan las opciones de paralelización de Github Actions, y proporciona una función para recopilar resultados una vez que se completan otros trabajos. Estoy usando esta función en libcgroup para finalizar sus números de cobertura de código después de que se hayan ejecutado todas las pruebas

Contras:

• Sin soporte nativo para otras arquitecturas

  • Un empleado de github proporcionó esta solución para ejecutar un contenedor de Docker arm64. Lo probé, y con algunos retoques pude hacer que el conjunto de pruebas básico funcionara en su mayor parte. (La prueba 52 - carga básica - falló por alguna extraña razón). Pero esta configuración es difícil de reproducir localmente y la depuración es un desafío significativo. No pude hacer funcionar las pruebas de Python. Ah, y es muy, muy lento: tomó una hora ejecutar un conjunto reducido de pruebas en arm64. ppc64el tomó 6 horas antes de que lo matara :(
  • Un usuario de github creó esta acción que también usa contenedores Docker para ejecutar arquitecturas no nativas. La sintaxis es algo torpe y nos obligaría a duplicar el código. Su arquitectura compatible
  • Github Actions admite el uso de corredores autohospedados, por lo que una opción (fea) sería encontrar un cuadro arm64, ppc64le, etc. dedicado y usarlo para ejecutar las pruebas. La ventaja de esto es que la depuración sería mucho más sencilla que un contenedor Docker.

Otro:

• Coveralls.io ha creado una acción de Github . Nuestra solución TravisCI existente, cpp-coveralls , funciona en Github Actions, pero tuvo problemas con las compilaciones paralelas. Tengo la acción de Coveralls trabajando en paralelo en libcgroup
• Para utilizar la acción de Coveralls , tuve que esta línea estaba cubierta o no, mientras que la solución Github Actions la llama explícitamente
• Nota personal: no tengo el indicador --exclude src/arch-syscall-check.c lcov funcionando. No tengo ni idea de por qué

¿Qué pasa con el uso de Vagrant en macOS?

¿Qué pasa con el uso de Vagrant en macOS?

Este problema trata específicamente de trasladar nuestras pruebas de CI de Travis CI a Acciones de GitHub y no del desarrollo y las pruebas generales de libseccomp. No estoy seguro de que MacOS sea una opción para las acciones de GitHub, e incluso si lo fuera, probablemente sería una mala elección para nosotros debido a la falta de soporte del kernel (nuestras pruebas "en vivo" son limitadas, pero importantes).

Aquí está mi estado actual. Tengo acciones de Github trabajando en amd64 con algunas desviaciones leves de nuestra solución actual de Travis CI, pero me preocupan otras arquitecturas.

Gracias por investigar este @drakenclimber , el soporte de arquitectura limitado es muy decepcionante. Dado que en realidad no estamos viendo muchos problemas con Travis CI en este momento, ¿quizás continuamos con Travis hasta que se vuelva disruptivo?

Con respecto a los comentarios de lcov / Coveralls; Había notado cosas similares en el pasado, pero no me preocupé demasiado por las diferencias, ya que eran menores. Me pregunto si sería posible usar lcov en Travis y cargar el archivo lcov como parte de la compilación de Travis sin perder credibilidad en la configuración de Travis. Si nada más, eso aportaría coherencia en el uso local y de Travis, y podría facilitar un poco las cosas si / cuando migramos de Travis CI.

¿Qué pasa con el uso de Vagrant en macOS?

Este problema trata específicamente de trasladar nuestras pruebas de CI de Travis CI a Acciones de GitHub y no del desarrollo y las pruebas generales de libseccomp. No estoy seguro de que MacOS sea una opción para las acciones de GitHub, e incluso si lo fuera, probablemente sería una mala elección para nosotros debido a la falta de soporte del kernel (nuestras pruebas "en vivo" son limitadas, pero importantes).

Estoy bastante familiarizado con las acciones de GitHub. Son compatibles con macOS (consulte: https://github.com/actions/virtual-environments#available-environments). Específicamente, macOS es el único entorno que viene con Vagrant y VirtualBox (consulte: https://github.com/actions/virtual-environments/issues/433).

En mi experiencia, la configuración requiere un poco más de trabajo, pero la ejecución dentro de una máquina virtual garantiza un entorno más consistente para las canalizaciones de CI / CD. Sin mencionar que es más portátil, ya que cualquiera puede ejecutar las imágenes de Vagrant / VirtualBox localmente. También facilita la migración a una nueva solución CI / CD, ya que la configuración generalmente se escribe en un script, independientemente de las declaraciones YAML específicas del proveedor.

Estos son mis únicos dos centavos :)

Gracias @ oxr463 , es bueno saber sobre GH Actions. En este punto, preferiría no tener la sobrecarga de administración adicional de un entorno virtual, pero es algo a considerar si Travis CI alguna vez se convierte en un problema para nosotros.

Como nuestra actividad de Travis es relativamente ligera, espero que no nos encontremos con los problemas de Travis que han visto algunos otros proyectos.

Gracias por investigar este @drakenclimber , el soporte de arquitectura limitado es muy decepcionante. Dado que en realidad no estamos viendo muchos problemas con Travis CI en este momento, ¿quizás continuamos con Travis hasta que se vuelva disruptivo?

Sí, creo que esa es la mejor y más segura respuesta.

Con respecto a los comentarios de lcov / Coveralls; Había notado cosas similares en el pasado, pero no me preocupé demasiado por las diferencias, ya que eran menores. Me pregunto si sería posible usar lcov en Travis y cargar el archivo lcov como parte de la compilación de Travis sin perder credibilidad en la configuración de Travis. Si nada más, eso aportaría coherencia en el uso local y de Travis, y podría facilitar un poco las cosas si / cuando migramos de Travis CI.

Sí, esto debería ser posible. Creé el número 309 y me lo asigné. Intentaré retomar esto en la próxima semana o dos.

Gracias

En mi experiencia, la configuración requiere un poco más de trabajo, pero la ejecución dentro de una máquina virtual garantiza un entorno más consistente para las canalizaciones de CI / CD. Sin mencionar que es más portátil, ya que cualquiera puede ejecutar las imágenes de Vagrant / VirtualBox localmente. También facilita la migración a una nueva solución CI / CD, ya que la configuración generalmente se escribe en un script, independientemente de las declaraciones YAML específicas del proveedor.

Gracias, @ oxr463. También espero que no tengamos que seguir ese camino, pero es bueno saber que existen otras opciones.

@drakenclimber Voy a eliminar esto de un hito de lanzamiento y reducir la prioridad a baja ya que estamos adoptando un enfoque de "esperar hasta que se rompa" para esto, si no está de acuerdo, no dude en gritar o simplemente ajustar las etiquetas en consecuencia.

@drakenclimber Voy a eliminar esto de un hito de lanzamiento y reducir la prioridad a baja ya que estamos adoptando un enfoque de "esperar hasta que se rompa" para esto, si no está de acuerdo, no dude en gritar o simplemente ajustar las etiquetas en consecuencia.

Suena bien para mí. ¡Gracias!

@drakenclimber se me acaba de ocurrir una cosa: deberíamos considerar intentar migrar de travis-ci.org a travis-ci.com ya que el ".org" supuestamente desaparecerá "en unas semanas".

¡Oh! No lo sabía. ¡Gracias!

Intentaré retomar esto la semana que viene.