Libseccomp: RFE: Übergang von travis-ci.org zu travis-ci.com

Ich habe mich bei travis-ci.com angemeldet, aber sie befinden sich noch in der Beta-Phase, daher können wir noch nicht umsteigen.

Bah! Sie machen es sich definitiv nicht leicht, oder? ;)

Da die Übergangsfrist noch "unscharf" ist, um es milde auszudrücken, werde ich dies aus dem Meilenstein v2.5.2 ziehen und es schweben lassen. Wir werden uns das irgendwann noch ansehen müssen, aber bis Travis den Umzug macht, gibt es hier nichts für uns zu tun.

Ich ging gerade, um zu überprüfen, ob der Travis-Build nach einigen Druckvorgängen in Ordnung war, und wurde von dieser Nachricht begrüßt:

Seit dem 15.06.2021 wird der Aufbau auf travis-ci.org eingestellt. Bitte nutzen Sie ab sofort travis-ci.com.

... es sieht so aus, als ob wir das herausfinden müssen, und zwar bald.

Ich bin ein wenig misstrauisch gegenüber Travis' neuem Geschäftsmodell. Es sieht so aus, als ob Open Source (vorerst) kostenlos bleiben wird, aber sie haben es sich nicht leicht gemacht. Möglicherweise müssen wir regelmäßig mehr "Credits" von ihnen anfordern.
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)

Puh, das ist scheiße :/

Ich muss mein Gedächtnis auffrischen, was Sie über GH Actions herausgefunden haben; es war alles andere als perfekt, aber in Anbetracht der Travis CI-Änderungen könnte es die bessere Option sein.

Los geht's ... #299

Okay, nachdem aktualisierte mein Gedächtnis auf # 299 Ich denke , die beste Option jetzt zu GH Aktionen zu migrieren ist und nur Stick auf x86_64 CI einstweilen aufbaut. Dies scheint der schnellste Weg zu sein, um PR-/Branchen- und Code-Coverage-Tests mit dem geringsten Aufwand wiederherzustellen.

Der Mangel an anderen Bögen/ABIs ist beunruhigend, aber realistischerweise testen wir sowieso nicht jeden Bogen/ABI regelmäßig (wie könnten wir?), also ist dies nicht das Ende der Welt. Wenn es hilft, obwohl es nicht "CI" ist, habe ich einen nächtlichen Job, der auf einer privaten Infrastruktur läuft, die den libseccomp-Hauptzweig auf aarch64 erstellt und überprüft; Wenn etwas kaputt geht, merke ich es innerhalb von 24 Stunden. Hoffentlich können wir in Zukunft etwas Besseres herausfinden (ich habe hier einige Ideen ...).

@drakenclimber Gedanken?

Ich denke, die beste Option ist derzeit, zu GH Actions zu migrieren und vorerst nur bei x86_64 CI-Builds zu bleiben. Dies scheint der schnellste Weg zu sein, um PR-/Branchen- und Code-Coverage-Tests mit dem geringsten Aufwand wiederherzustellen.

Klingt gut für mich. Ich kann den Übergang besitzen, da ich ihn bereits für libcgroup gemacht habe.

Wir verwenden Github Actions in der libcgroup schon seit einiger Zeit und es hat ziemlich gut funktioniert. Die Aufträge waren von Travis leicht zu übertragen.

Die Github Actions-VMs boten keine Funktion, die wir in libcgroup (einem vollständigen cgroup v2-System) benötigten, daher habe ich kürzlich eine VM in der Oracle Free Cloud erstellt und über den selbst gehosteten Runner von Github Actions verbunden . Es war einfach einzurichten und hat bisher gut funktioniert. Ich glaube, dass die selbst gehostete Runner-Logik von GH Actions aarch64 unterstützt, so dass dies eine Möglichkeit sein könnte, ARM kontinuierlich zu testen, wenn wir eine Box hätten, auf die wir verweisen könnten.

Der Mangel an anderen Bögen/ABIs ist beunruhigend, aber realistischerweise testen wir sowieso nicht jeden Bogen/ABI regelmäßig (wie könnten wir?), also ist dies nicht das Ende der Welt.

Einverstanden. Mir hat die Palette der derzeit getesteten Architekturen gefallen, da gelegentlich seltsame 32- vs. 64-Bit- und Big- vs. Little-Endian-Probleme auftreten. Vor einer Veröffentlichung sollten wir die Tests (zumindest) auf anderen Architekturen durchführen. Vielleicht können wir ehemalige Mitwirkende rekrutieren, um hier zu helfen.

(Ich habe hier einige Ideen ...).

Ich bin ganz Ohr. Ich wünschte, ich könnte die besten Teile von GH Actions und Travis nehmen und in ein CI packen.

(Ich habe hier einige Ideen ...)

Entschuldigung, ich hätte deutlicher sein sollen. Ich meinte, ich habe vielleicht einige Ideen zur Unterstützung von aarch64, nicht zu Travis/GH im Allgemeinen.

Trotzdem danke für Ihre Arbeit in PR #329.