Libseccomp: RFE : Transition de travis-ci.org vers travis-ci.com

Je me suis connecté à travis-ci.com, mais ils sont encore en phase bêta, nous ne pouvons donc pas encore effectuer la transition.

Bah ! Ils ne facilitent certainement pas les choses, n'est-ce pas ? ;)

Étant donné que la date limite de transition est encore "floue" pour le moins, je vais tirer cela du jalon v2.5.2 et le laisser flotter. Nous devrons toujours examiner cela à un moment donné, mais jusqu'à ce que Travis fasse le pas, nous n'avons rien à faire ici.

Je suis juste allé vérifier que la construction de Travis s'est bien terminée après quelques poussées et j'ai été accueilli par ce message :

Depuis le 15 juin 2021, la construction sur travis-ci.org est à l'arrêt. Veuillez utiliser travis-ci.com à partir de maintenant.

... il semble que nous devions comprendre cela, et bientôt.

Je me méfie un peu du nouveau modèle commercial de Travis. Il semble que l'open source restera gratuit (pour l'instant), mais ils ne l'ont pas rendu facile. Nous pouvons avoir besoin de leur demander périodiquement plus de « crédits ».
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)

Euh, c'est nul :/

Je dois me rafraîchir la mémoire sur ce que vous avez découvert sur GH Actions ; c'était loin d'être parfait, mais compte tenu des changements de Travis CI, cela pourrait être la meilleure option.

C'est parti... #299

D'accord, après avoir rafraîchi ma mémoire sur #299, je pense que la meilleure option pour le moment est de migrer vers GH Actions et de s'en tenir uniquement aux builds x86_64 CI pour le moment. Cela semble être le chemin le plus rapide pour restaurer les tests de couverture de PR/branche et de code avec le moins de maux de tête.

Le manque d'autres arches/ABI est troublant, mais de façon réaliste, nous ne testons pas chaque arch/ABI régulièrement de toute façon (comment pourrions-nous ?), donc ce n'est pas la fin du monde. Si cela aide, bien que ce ne soit pas "CI", j'ai un travail nocturne qui s'exécute sur une infrastructure privée qui construit et vérifie la branche principale de libseccomp sur aarch64; si quelque chose se brise, je le remarquerai dans environ 24 heures. Espérons que nous pourrons trouver quelque chose de mieux à l'avenir (j'ai quelques idées ici ...).

pensées de @drakenclimber ?

Je pense que la meilleure option pour le moment est de migrer vers GH Actions et de s'en tenir uniquement aux builds x86_64 CI pour le moment. Cela semble être le chemin le plus rapide pour restaurer les tests de couverture de PR/branche et de code avec le moins de maux de tête.

Cela me semble bien. Je peux posséder la transition puisque je l'ai déjà fait pour libcgroup.

Nous utilisons Github Actions dans libcgroup depuis un certain temps maintenant, et cela a plutôt bien fonctionné. Les emplois étaient faciles à transférer depuis Travis.

Les actions Github VMs n'a pas fourni une fonctionnalité dont nous avions besoin libcgroup (système v2 cgroup complet), donc je récemment créé une machine virtuelle sur l'Oracle Free Cloud et connecté vers le haut par auto-hébergé coureur de Github Actions. Il a été facile à installer et jusqu'à présent, il a bien fonctionné. Je pense que la logique d'exécution auto-hébergée de GH Actions prend en charge aarch64. Cela pourrait donc être un moyen de tester en continu ARM si nous avions une boîte vers laquelle nous pourrions la pointer.

Le manque d'autres arches/ABI est troublant, mais de façon réaliste, nous ne testons pas chaque arch/ABI régulièrement de toute façon (comment pourrions-nous ?), donc ce n'est pas la fin du monde.

D'accord. J'ai aimé la gamme d'architectures actuellement testées car on trouve parfois des problèmes étranges de 32 contre 64 bits et de gros contre petit boutien. Avant une version, nous devrions (au minimum) exécuter les tests sur d'autres architectures. Peut-être pouvons-nous recruter d'anciens contributeurs pour nous aider ici.

(j'ai quelques idées ici...).

Je suis tout ouïe. J'aimerais pouvoir prendre les meilleures parties de GH Actions et Travis et les mettre dans un seul CI.

(j'ai quelques idées ici...)

Désolé, j'aurais dû être plus clair. Je voulais dire que j'ai peut-être quelques idées sur le support d'aarch64, pas sur Travis/GH en général.

Quoi qu'il en soit, merci pour votre travail sur ce sujet dans PR #329.