Libseccomp: BUG: Ersetzen Sie Travis CI durch GitHub-Aktionen

Hier ist eine Anleitung für die Migration von TravisCI zu Github Actions. Ich hoffe, dass ich in den nächsten Tagen damit experimentieren kann
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions/migrating-from-travis-ci-to-github-actions

Das Aussehen von Github Actions gefällt mir sehr gut. Ich habe gerade ein Patchset verschickt, um die libcgroup von Travis CI auf Github Actions umzustellen.

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

Ich werde versuchen, diese Woche ein Patchset für die Umstellung auf libseccomp zusammenzustellen.

Das hört sich gut an @drakenclimber , danke!

Hier mein aktueller Stand. Ich habe Github Actions, die an AMD64 arbeiten, mit einigen leichten Abweichungen von unserer aktuellen Travis CI-Lösung, aber ich habe Bedenken bezüglich anderer Architekturen.

Vorteile:

• Einfach zu verwenden. Ich konnte schnell einen Continuous-Integration-Workflow in Github Actions einrichten
• Es ist auch einfach, Operationen in eine Aktion zu kapseln. Diese Aktionen können dann innerhalb des Workflows wiederverwendet werden. (Seltsamerweise kann eine Aktion keine andere Aktion aufrufen .)
• Akzeptable Geschwindigkeit (zumindest für AMD64). Die gesamte Testsuite in 22 Minuten abgeschlossen
• Gute GUI und fehlgeschlagene Schritte sind klar abgegrenzt
• Ich mag die Parallelisierungsoptionen von Github Actions sehr und bietet eine Funktion zum Zusammenstellen von Ergebnissen, sobald andere Jobs abgeschlossen sind. Ich verwende diese Funktion in libcgroup, um die Code-Coverage-Nummern abzuschließen, nachdem alle Tests ausgeführt wurden

Nachteile:

• Keine native Unterstützung für andere Architekturen
  
  
  
  • Ein github-Mitarbeiter hat diesen Workaround bereitgestellt, um einen arm64-Docker-Container auszuführen. Ich habe es ausprobiert und mit etwas Fummelei konnte ich die grundlegende Testsuite größtenteils zum Laufen bringen. (Test 52 - Grundlast - ist aus irgendeinem Grund fehlgeschlagen.) Aber dieses Setup ist lokal schwer zu reproduzieren und das Debuggen ist eine große Herausforderung. Ich konnte die Python-Tests nicht zum Laufen bringen. Oh, und es ist wirklich sehr langsam - es dauerte eine Stunde, um eine reduzierte Reihe von Tests auf arm64 auszuführen. ppc64el hat 6 Stunden gebraucht, bevor ich es getötet habe :(
  
  
  • Ein Github-Benutzer hat diese Aktion erstellt , die auch Docker-Container verwendet, um nicht-native Architekturen auszuführen. Die Syntax ist etwas klobig und würde erfordern, dass wir Code duplizieren. Die Liste der unterstützten
  
  
  • Github Actions unterstützt die Verwendung von selbst gehosteten Runnern , daher wäre eine (hässliche) Option, eine dedizierte arm64-, ppc64le- usw. -Box zu finden und diese zum Ausführen der Tests zu verwenden. Dies hat den Vorteil, dass das Debuggen viel einfacher wäre als ein Docker-Container
  
  

Sonstiges:

• Coveralls.io hat eine Github-Aktion erstellt . Unsere bestehende TravisCI-Lösung cpp-coveralls funktioniert zwar mit Github Actions, hatte aber Probleme mit parallelen Builds. Ich habe die Overalls-Aktion parallel in libcgroup
• Um die Aktion von Coveralls zu nutzen, musste ich lcov direkt aufrufen , um eine lcov.info-Datei zu generieren. Diese Datei wird dann auf coveralls.io hochgeladen. Beachten Sie, dass die direkte Verwendung von lcov leicht unterschiedliche Abdeckungszahlen erzeugt. Beispielsweise gibt die Travis CI-Lösung nicht an, ob diese Leitung abgedeckt war oder nicht, während die Github Actions-Lösung sie explizit uncovered nennt . Ich glaube, Github Actions ist in diesem Fall richtig und unsere aktuelle Lösung gibt die Abdeckungsnummer leicht falsch an
• Hinweis an mich selbst - Ich habe das --exclude src/arch-syscall-check.c lcov-Flag nicht funktioniert. Keine Ahnung warum

Hier mein aktueller Stand. Ich habe Github Actions, die an AMD64 arbeiten, mit einigen leichten Abweichungen von unserer aktuellen Travis CI-Lösung, aber ich habe Bedenken bezüglich anderer Architekturen.

Vorteile:

• Einfach zu verwenden. Ich konnte schnell einen Continuous-Integration-Workflow in Github Actions einrichten
• Es ist auch einfach, Operationen in eine Aktion zu kapseln. Diese Aktionen können dann innerhalb des Workflows wiederverwendet werden. (Seltsamerweise kann eine Aktion keine andere Aktion aufrufen .)
• Akzeptable Geschwindigkeit (zumindest für AMD64). Die gesamte Testsuite in 22 Minuten abgeschlossen
• Gute GUI und fehlgeschlagene Schritte sind klar abgegrenzt
• Ich mag die Parallelisierungsoptionen von Github Actions sehr und bietet eine Funktion zum Zusammenstellen von Ergebnissen, sobald andere Jobs abgeschlossen sind. Ich verwende diese Funktion in libcgroup, um die Code-Coverage-Nummern abzuschließen, nachdem alle Tests ausgeführt wurden

Nachteile:

• Keine native Unterstützung für andere Architekturen

  • Ein github-Mitarbeiter hat diesen Workaround bereitgestellt, um einen arm64-Docker-Container auszuführen. Ich habe es ausprobiert und mit etwas Fummelei konnte ich die grundlegende Testsuite größtenteils zum Laufen bringen. (Test 52 - Grundlast - ist aus irgendeinem Grund fehlgeschlagen.) Aber dieses Setup ist lokal schwer zu reproduzieren und das Debuggen ist eine große Herausforderung. Ich konnte die Python-Tests nicht zum Laufen bringen. Oh, und es ist wirklich sehr langsam - es dauerte eine Stunde, um eine reduzierte Reihe von Tests auf arm64 auszuführen. ppc64el hat 6 Stunden gebraucht, bevor ich es getötet habe :(
  • Ein Github-Benutzer hat diese Aktion erstellt , die auch Docker-Container verwendet, um nicht-native Architekturen auszuführen. Die Syntax ist etwas klobig und würde erfordern, dass wir Code duplizieren. Die Liste der unterstützten
  • Github Actions unterstützt die Verwendung von selbst gehosteten Runnern , daher wäre eine (hässliche) Option, eine dedizierte arm64-, ppc64le- usw. -Box zu finden und diese zum Ausführen der Tests zu verwenden. Dies hat den Vorteil, dass das Debuggen viel einfacher wäre als ein Docker-Container

Sonstiges:

• Coveralls.io hat eine Github-Aktion erstellt . Unsere bestehende TravisCI-Lösung cpp-coveralls funktioniert zwar mit Github Actions, hatte aber Probleme mit parallelen Builds. Ich habe die Overalls-Aktion parallel in libcgroup
• Um die Aktion von Coveralls zu nutzen, musste ich lcov direkt aufrufen , um eine lcov.info-Datei zu generieren. Diese Datei wird dann auf coveralls.io hochgeladen. Beachten Sie, dass die direkte Verwendung von lcov leicht unterschiedliche Abdeckungszahlen erzeugt. Beispielsweise gibt die Travis CI-Lösung nicht an, ob diese Leitung abgedeckt war oder nicht, während die Github Actions-Lösung sie explizit uncovered nennt . Ich glaube, Github Actions ist in diesem Fall richtig und unsere aktuelle Lösung gibt die Abdeckungsnummer leicht falsch an
• Hinweis an mich selbst - Ich habe das --exclude src/arch-syscall-check.c lcov-Flag nicht funktioniert. Keine Ahnung warum

Wie sieht es mit der Verwendung von Vagrant unter macOS aus?

Wie sieht es mit der Verwendung von Vagrant unter macOS aus?

In diesem Thema geht es speziell um die Verlagerung unserer CI-Tests von Travis CI auf GitHub Actions und nicht um die allgemeine Entwicklung und das Testen von libseccomp. Ich bin mir nicht sicher, ob MacOS eine Option für GitHub-Aktionen ist, und selbst wenn es so wäre, wäre es aufgrund der fehlenden Kernel-Unterstützung wahrscheinlich eine schlechte Wahl für uns (unsere "Live" -Tests sind begrenzt, aber wichtig).

Hier mein aktueller Stand. Ich habe Github Actions, die an AMD64 arbeiten, mit einigen leichten Abweichungen von unserer aktuellen Travis CI-Lösung, aber ich habe Bedenken bezüglich anderer Architekturen.

Vielen Dank, dass Sie sich diesen @drakenclimber angesehen haben , die eingeschränkte Architekturunterstützung ist sehr enttäuschend. Da wir im Moment mit Travis CI eigentlich nicht viele Probleme sehen, machen wir vielleicht mit Travis weiter, bis es störend wird?

Zu den Kommentaren von lcov/Overalls; Ich hatte in der Vergangenheit ähnliche Dinge bemerkt, machte mir aber keine großen Sorgen über die Unterschiede, da sie geringfügig waren. Ich frage mich, ob es möglich wäre, lcov in Travis zu verwenden und die lcov-Datei als Teil des Travis-Builds hochzuladen, ohne irgendwelche Creds in der Travis-Konfiguration zu verlieren? Wenn nichts anderes, würde dies Konsistenz zwischen lokaler und Travis-Nutzung bringen, und es könnte die Dinge etwas einfacher machen, wenn/wenn wir weg von Travis CI migrieren.

Wie sieht es mit der Verwendung von Vagrant unter macOS aus?

In diesem Thema geht es speziell um die Verlagerung unserer CI-Tests von Travis CI auf GitHub Actions und nicht um die allgemeine Entwicklung und das Testen von libseccomp. Ich bin mir nicht sicher, ob MacOS eine Option für GitHub-Aktionen ist, und selbst wenn es so wäre, wäre es aufgrund der fehlenden Kernel-Unterstützung wahrscheinlich eine schlechte Wahl für uns (unsere "Live" -Tests sind begrenzt, aber wichtig).

Ich bin mit GitHub-Aktionen ziemlich vertraut. Sie unterstützen macOS (Siehe: https://github.com/actions/virtual-environments#available-environments). Insbesondere ist macOS die einzige Umgebung, die mit Vagrant und VirtualBox geliefert wird (siehe: https://github.com/actions/virtual-environments/issues/433).

Meiner Erfahrung nach erfordert die Einrichtung etwas mehr Arbeit, aber die Ausführung in einer virtuellen Maschine gewährleistet eine konsistentere Umgebung für CI/CD-Pipelines. Ganz zu schweigen davon, dass es portabler ist, da jeder die Vagrant/VirtualBox-Images lokal ausführen kann. Es erleichtert auch die Migration zu einer neuen CI/CD-Lösung, da die Konfiguration in der Regel unabhängig von den herstellerspezifischen YAML-Deklarationen in einem Skript geschrieben wird.

Das sind nur meine zwei Cent :)

Danke @oxr463 , das ist gut zu wissen über GH Actions. An dieser Stelle würde ich es vorziehen, nicht den zusätzlichen Verwaltungsaufwand einer virtuellen Umgebung zu haben, aber es ist eine Überlegung, ob Travis CI jemals ein Problem für uns wird.

Da unsere Travis-Aktivität relativ gering ist, hoffe ich, dass wir nicht auf die Travis-Probleme stoßen, die bei einigen anderen Projekten aufgetreten sind.

Vielen Dank, dass Sie sich diesen @drakenclimber angesehen haben , die eingeschränkte Architekturunterstützung ist sehr enttäuschend. Da wir im Moment mit Travis CI eigentlich nicht viele Probleme sehen, machen wir vielleicht mit Travis weiter, bis es störend wird?

Ja, ich denke, das ist die beste und sicherste Antwort.

Zu den Kommentaren von lcov/Overalls; Ich hatte in der Vergangenheit ähnliche Dinge bemerkt, machte mir aber keine großen Sorgen über die Unterschiede, da sie geringfügig waren. Ich frage mich, ob es möglich wäre, lcov in Travis zu verwenden und die lcov-Datei als Teil des Travis-Builds hochzuladen, ohne irgendwelche Creds in der Travis-Konfiguration zu verlieren? Wenn nichts anderes, würde dies Konsistenz zwischen lokaler und Travis-Nutzung bringen, und es könnte die Dinge etwas einfacher machen, wenn/wenn wir weg von Travis CI migrieren.

Ja, das sollte möglich sein. Ich habe Issue #309 erstellt und mir selbst zugewiesen. Ich werde versuchen, das in den nächsten ein oder zwei Wochen zu holen.

Vielen Dank

Meiner Erfahrung nach erfordert die Einrichtung etwas mehr Arbeit, aber die Ausführung in einer virtuellen Maschine gewährleistet eine konsistentere Umgebung für CI/CD-Pipelines. Ganz zu schweigen davon, dass es portabler ist, da jeder die Vagrant/VirtualBox-Images lokal ausführen kann. Es erleichtert auch die Migration zu einer neuen CI/CD-Lösung, da die Konfiguration in der Regel unabhängig von den herstellerspezifischen YAML-Deklarationen in einem Skript geschrieben wird.

Danke, @oxr463. Ich hoffe auch, dass wir diesen Weg nicht gehen müssen, aber es ist gut zu wissen, dass es da draußen noch andere Möglichkeiten gibt.

@drakenclimber Ich werde dies von einem Veröffentlichungsmeilenstein senken , da wir einen "Warten, bis es bricht"-Ansatz

@drakenclimber Ich werde dies von einem Veröffentlichungsmeilenstein senken , da wir einen "Warten, bis es bricht"-Ansatz

Klingt gut für mich. Vielen Dank!

@drakenclimber eine Sache ist mir gerade

Oh! Wusste das nicht. Vielen Dank!

Das werde ich dann nächste Woche versuchen nachzuholen.