Libseccomp: BOGUE : envisagez de remplacer Travis CI par des actions GitHub

Créé le 6 nov. 2020  ·  14Commentaires  ·  Source: seccomp/libseccomp

Il existe de nombreux articles à ce sujet, mais consultez l'article The Register ci-dessous pour obtenir des informations sur ce problème :

Travis CI devenant potentiellement peu fiable pour libseccomp, nous devrions envisager de déplacer les tests CI vers les actions GitHub :

bug prioritlow

Commentaire le plus utile

J'aime beaucoup le look de Github Actions. Je viens d'envoyer un patchset pour passer de libcgroup de Travis CI à Github Actions.

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

Je vais essayer de mettre en place un ensemble de correctifs pour la transition libseccomp cette semaine.

Tous les 14 commentaires

Voici un guide pour migrer de TravisCI vers Github Actions. J'espère expérimenter cela dans les prochains jours
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions/migrating-from-travis-ci-to-github-actions

J'aime beaucoup le look de Github Actions. Je viens d'envoyer un patchset pour passer de libcgroup de Travis CI à Github Actions.

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

Je vais essayer de mettre en place un ensemble de correctifs pour la transition libseccomp cette semaine.

Ça sonne bien @drakenclimber , merci !

Voici mon statut actuel. J'ai Github Actions qui travaille sur amd64 avec quelques légers écarts par rapport à notre solution Travis CI actuelle, mais j'ai des inquiétudes concernant d'autres architectures.

Avantages:

Les inconvénients:

  • Pas de support natif pour d'autres architectures

    • Un employé de github a fourni cette solution de suite de tests de base . (Le test 52 - charge de base - a échoué pour une raison étrange.) Mais cette configuration est difficile à reproduire localement et le débogage est un défi important. Je n'ai pas réussi à faire fonctionner les tests python. Oh, et c'est vraiment, vraiment lent - il a fallu une heure pour exécuter une série de tests réduits sur arm64. ppc64el a pris 6 heures avant de le tuer :(

    • Un utilisateur de github a créé cette action qui utilise également des conteneurs Docker pour exécuter des architectures non natives. La syntaxe est quelque peu maladroite et nous obligerait à dupliquer le code. Son architecture et sa liste de plates-formes prises en charge sont assez bonnes, cependant

    • Github Actions prend en charge l'utilisation de coureurs auto-hébergés , donc une option (laide) serait de trouver une boîte dédiée arm64, ppc64le, etc. et de l'utiliser pour exécuter les tests. L'avantage de ceci est que le débogage serait beaucoup plus simple qu'un conteneur Docker

Autre:

  • Coveralls.io a créé une action Github . Notre solution TravisCI existante, cpp-coveralls , fonctionne sur les actions Github, mais elle a eu du mal avec les versions parallèles. J'ai l'action Combinaisons fonctionnant en parallèle dans libcgroup
  • Pour utiliser l'action de Coveralls, j'ai dû appeler directement lcov pour générer un fichier lcov.info. Ce fichier est ensuite téléchargé sur coveralls.io. Notez que l'utilisation de lcov produit directement des nombres de couverture légèrement différents. Par exemple, la solution Travis CI ne précise pas si cette ligne était couverte ou non alors que la solution Github Actions l' appelle explicitement
  • Note à moi-même - Je n'ai pas le drapeau lcov --exclude src/arch-syscall-check.c qui fonctionne. Aucune idée pourquoi

Voici mon statut actuel. J'ai Github Actions qui travaille sur amd64 avec quelques légers écarts par rapport à notre solution Travis CI actuelle, mais j'ai des inquiétudes concernant d'autres architectures.

Avantages:

Les inconvénients:

  • Pas de support natif pour d'autres architectures

    • Un employé de github a fourni cette solution de suite de tests de base . (Le test 52 - charge de base - a échoué pour une raison étrange.) Mais cette configuration est difficile à reproduire localement et le débogage est un défi important. Je n'ai pas réussi à faire fonctionner les tests python. Oh, et c'est vraiment, vraiment lent - il a fallu une heure pour exécuter une série de tests réduits sur arm64. ppc64el a pris 6 heures avant de le tuer :(
    • Un utilisateur de github a créé cette action qui utilise également des conteneurs Docker pour exécuter des architectures non natives. La syntaxe est quelque peu maladroite et nous obligerait à dupliquer le code. Son architecture et sa liste de plates-formes prises en charge sont assez bonnes, cependant
    • Github Actions prend en charge l'utilisation de coureurs auto-hébergés , donc une option (laide) serait de trouver une boîte dédiée arm64, ppc64le, etc. et de l'utiliser pour exécuter les tests. L'avantage de ceci est que le débogage serait beaucoup plus simple qu'un conteneur Docker

Autre:

  • Coveralls.io a créé une action Github . Notre solution TravisCI existante, cpp-coveralls , fonctionne sur les actions Github, mais elle a eu du mal avec les versions parallèles. J'ai l'action Combinaisons fonctionnant en parallèle dans libcgroup
  • Pour utiliser l'action de Coveralls, j'ai dû appeler directement lcov pour générer un fichier lcov.info. Ce fichier est ensuite téléchargé sur coveralls.io. Notez que l'utilisation de lcov produit directement des nombres de couverture légèrement différents. Par exemple, la solution Travis CI ne précise pas si cette ligne était couverte ou non alors que la solution Github Actions l' appelle explicitement
  • Note à moi-même - Je n'ai pas le drapeau lcov --exclude src/arch-syscall-check.c qui fonctionne. Aucune idée pourquoi

Et si vous utilisiez Vagrant sur macOS ?

Et si vous utilisiez Vagrant sur macOS ?

Ce problème concerne spécifiquement le déplacement de nos tests CI de Travis CI vers GitHub Actions et non le développement et les tests généraux de libseccomp. Je ne suis pas sûr que MacOS soit une option pour les actions GitHub, et même si c'était le cas, ce serait probablement un mauvais choix pour nous en raison du manque de prise en charge du noyau (nos tests "en direct" sont limités, mais importants).

Voici mon statut actuel. J'ai Github Actions qui travaille sur amd64 avec quelques légers écarts par rapport à notre solution Travis CI actuelle, mais j'ai des inquiétudes concernant d'autres architectures.

Merci d'avoir examiné ce @drakenclimber , la prise en charge limitée de l'architecture est très décevante. Étant donné que nous ne voyons pas beaucoup de problèmes avec Travis CI pour le moment, peut-être continuerons-nous avec Travis jusqu'à ce que cela devienne perturbateur ?

Concernant les commentaires lcov/Coveralls; J'avais remarqué des choses similaires dans le passé, mais je ne m'inquiétais pas trop des différences car elles étaient mineures. Je me demande s'il serait possible d'utiliser lcov dans Travis et de télécharger le fichier lcov dans le cadre de la construction de Travis sans divulguer de crédits dans la configuration de Travis? Au moins, cela apporterait une cohérence entre l'utilisation locale et Travis, et cela pourrait rendre les choses un peu plus faciles si/quand nous migrons à partir de Travis CI.

Et si vous utilisiez Vagrant sur macOS ?

Ce problème concerne spécifiquement le déplacement de nos tests CI de Travis CI vers GitHub Actions et non le développement et les tests généraux de libseccomp. Je ne suis pas sûr que MacOS soit une option pour les actions GitHub, et même si c'était le cas, ce serait probablement un mauvais choix pour nous en raison du manque de prise en charge du noyau (nos tests "en direct" sont limités, mais importants).

Je connais assez bien les actions GitHub. Ils prennent en charge macOS (voir : https://github.com/actions/virtual-environments#available-environments). Plus précisément, macOS est le seul environnement fourni avec Vagrant et VirtualBox (voir : https://github.com/actions/virtual-environments/issues/433).

D'après mon expérience, la configuration nécessite un peu plus de travail, mais l'exécution à l'intérieur d'une machine virtuelle garantit un environnement plus cohérent pour les pipelines CI/CD. Sans oublier qu'il est plus portable, puisque n'importe qui peut exécuter les images Vagrant/VirtualBox localement. Cela facilite également la migration vers une nouvelle solution CI/CD, car la configuration est généralement écrite dans un script, indépendamment des déclarations YAML spécifiques au fournisseur.

Ce ne sont que mes deux cents :)

Merci @ oxr463 , c'est bon à savoir sur GH Actions. À ce stade, je préférerais ne pas avoir la charge de gestion supplémentaire d'un environnement virtuel, mais c'est quelque chose à considérer si Travis CI devient un problème pour nous.

Comme notre activité Travis est relativement légère, j'espère que nous ne rencontrerons pas les problèmes Travis que d'autres projets ont rencontrés.

Merci d'avoir examiné ce @drakenclimber , la prise en charge limitée de l'architecture est très décevante. Étant donné que nous ne voyons pas beaucoup de problèmes avec Travis CI pour le moment, peut-être continuerons-nous avec Travis jusqu'à ce que cela devienne perturbateur ?

Oui, je pense que c'est la réponse la meilleure et la plus sûre.

Concernant les commentaires lcov/Coveralls; J'avais remarqué des choses similaires dans le passé, mais je ne m'inquiétais pas trop des différences car elles étaient mineures. Je me demande s'il serait possible d'utiliser lcov dans Travis et de télécharger le fichier lcov dans le cadre de la construction de Travis sans divulguer de crédits dans la configuration de Travis? Au moins, cela apporterait une cohérence entre l'utilisation locale et Travis, et cela pourrait rendre les choses un peu plus faciles si/quand nous migrons à partir de Travis CI.

Oui, cela devrait être possible. J'ai créé le numéro 309 et je me l'ai attribué. J'essaierai de récupérer ça d'ici une semaine ou deux.

Merci

D'après mon expérience, la configuration nécessite un peu plus de travail, mais l'exécution à l'intérieur d'une machine virtuelle garantit un environnement plus cohérent pour les pipelines CI/CD. Sans oublier qu'il est plus portable, puisque n'importe qui peut exécuter les images Vagrant/VirtualBox localement. Cela facilite également la migration vers une nouvelle solution CI/CD, car la configuration est généralement écrite dans un script, indépendamment des déclarations YAML spécifiques au fournisseur.

Merci, @oxr463. J'espère également que nous n'aurons pas à emprunter cette voie, mais il est bon de savoir qu'il existe d'autres options.

@drakenclimber Je vais laisser tomber cela d'un jalon de sortie et baisser la priorité à bas puisque nous adoptons une approche "attendre jusqu'à ce que ça casse", si vous n'êtes pas d'accord, n'hésitez pas à crier ou simplement ajuster les étiquettes en conséquence.

@drakenclimber Je vais laisser tomber cela d'un jalon de sortie et baisser la priorité à bas puisque nous adoptons une approche "attendre jusqu'à ce que ça casse", si vous n'êtes pas d'accord, n'hésitez pas à crier ou simplement ajuster les étiquettes en conséquence.

Cela me semble bien. Merci!

@drakenclimber, une chose m'est venue à l'esprit - nous devrions envisager d'essayer de migrer de travis-ci.org vers travis-ci.com car le ".org" est censé disparaître "dans quelques semaines".

Oh! Je ne le savais pas. Merci!

J'essaierai de récupérer ça la semaine prochaine alors.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

kloetzl picture kloetzl  ·  19Commentaires

cgwalters picture cgwalters  ·  14Commentaires

varqox picture varqox  ·  23Commentaires

grubeli picture grubeli  ·  3Commentaires

srd424 picture srd424  ·  18Commentaires