Libseccomp: RFE: Transición de travis-ci.org a travis-ci.com

Me conecté a travis-ci.com, pero todavía están en la fase beta, por lo que aún no podemos realizar la transición.

¡Bah! Definitivamente no lo están haciendo fácil, ¿verdad? ;)

Dado que la fecha límite de transición aún es "difusa", por decirlo suavemente, voy a sacar esto del hito v2.5.2 y dejarlo flotar. Todavía tendremos que mirar esto en algún momento, pero hasta que Travis haga el movimiento, no hay nada que podamos hacer aquí.

Solo fui a verificar que la compilación de Travis se completó bien después de algunos empujones y me recibió este mensaje:

Desde el 15 de junio de 2021, se dejó de construir en travis-ci.org. Utilice travis-ci.com a partir de ahora.

... parece que tenemos que resolver esto, y pronto.

Estoy un poco receloso del nuevo modelo de negocio de Travis. Parece que el código abierto seguirá siendo gratuito (por ahora), pero no lo han facilitado. Es posible que debamos solicitarles periódicamente más "créditos".
https://docs.travis-ci.com/user/billing-faq/#what -if-i-am-building-open-source

What if I am building open source? #

Each of the Travis CI Plans contains an amount of special OSS credits per month assigned to
run builds only on public repositories. To find out more about it please contact the Travis CI
support team. In the email please include:

* Your account name and your VCS provider (like travis-ci.com/github/[your account name] )
* How many credits (build minutes) you’d like to request (should your run out of credits again
  you can repeat the process to request more or to discuss a renewable amount)

Ugh, eso apesta: /

Necesito refrescarme la memoria sobre lo que averiguó sobre GH Actions; estaba lejos de ser perfecto, pero considerando los cambios de Travis CI, podría ser la mejor opción.

Aquí vamos ... # 299

De acuerdo, habiendo refrescado mi memoria en el n. ° 299, creo que la mejor opción en este momento es migrar a GH Actions y ceñirse solo a las compilaciones x86_64 CI por el momento. Ese parece ser el camino más rápido para restaurar las pruebas de cobertura de código / sucursales y relaciones públicas con la menor cantidad de dolores de cabeza.

La falta de otros arcos / ABI es preocupante, pero de manera realista no probamos todos los arcos / ABI de forma regular de todos modos (¿cómo podríamos?) Así que este no es el fin del mundo. Si ayuda, aunque no es "CI", tengo un trabajo nocturno que se ejecuta en una infraestructura privada que construye y verifica la rama principal libseccomp en aarch64; si algo se rompe, lo notaré en unas 24 horas. Ojalá podamos encontrar algo mejor en el futuro (tengo algunas ideas aquí ...).

@drakenclimber pensamientos?

Creo que la mejor opción en este momento es migrar a GH Actions y ceñirse solo a las compilaciones de CI x86_64 por el momento. Ese parece ser el camino más rápido para restaurar las pruebas de cobertura de código / sucursales y relaciones públicas con la menor cantidad de dolores de cabeza.

Suena bien para mí. Puedo poseer la transición ya que ya lo hice para libcgroup.

Hemos estado usando Github Actions en libcgroup durante bastante tiempo y ha funcionado bastante bien. Los trabajos fueron fáciles de transferir desde Travis.

Las VM de Github Actions no proporcionaban una característica que necesitábamos en libcgroup (un sistema completo de cgroup v2), por lo que recientemente creé una VM en Oracle Free Cloud y la conecté a través del corredor autohospedado de Github Actions. Fue fácil de configurar y hasta ahora ha funcionado bien. Creo que la lógica del corredor autohospedado de GH Actions es compatible con aarch64, por lo que esta podría ser una forma de probar ARM de forma continua si tuviéramos una casilla a la que pudiéramos apuntar.

La falta de otros arcos / ABI es preocupante, pero de manera realista no probamos todos los arcos / ABI de forma regular de todos modos (¿cómo podríamos?) Así que este no es el fin del mundo.

Acordado. Me ha gustado la variedad de arquitecturas que se prueban actualmente, ya que ocasionalmente se encuentran problemas extraños de 32 vs 64 bits y big-vs little-endian. Antes de un lanzamiento, deberíamos (como mínimo) ejecutar las pruebas en otras arquitecturas. Quizás podamos reclutar a contribuyentes anteriores para que ayuden aquí.

(Tengo algunas ideas aquí ...).

Soy todo oídos. Ojalá pudiera tomar las mejores partes de GH Actions y Travis y ponerlas en un CI.

(Tengo algunas ideas aquí ...)

Lo siento, debería haber sido más claro. Quiero decir que puedo tener algunas ideas sobre el apoyo a aarch64, no sobre Travis / GH en general.

Independientemente, gracias por trabajar en esto en PR # 329.