(Python) CI Services / Travis Alternativen?
Hallo, für eines meiner Open Source Python Projekte [1] will ich (lange überfällig) automatisiertes Testing und Building einführen. Leider musste ich feststellen, das die übliche Lösung, Travis CI, für dieses Projekt nicht geeignet ist, weil die Tests das ALSA MIDI Sequencer Kernelmodul brauchen und man in den OpenVZ-Umgebungen von Travis keine Kernelmodule laden kann. Welche Alternativen gibt es? Anforderungen: freier Plan für OS-Projekte, ALSA-Sequencer vorhanden oder ladbar und Zugriff auf Build-Artefakte, sprich Sdists, Eggs und Wheels. Idealerweise auch OS X und Windows Umgebungen. drone.io hatte ich mir auch angeschaut und es sah auf den ersten Blick ganz gut aus. Als ich es jedoch ausprobieren wollte, sollte ich vollen (also Lese- *und Schreib*zugriff) auf mein Github-Profil erlauben. Das hat den Service für mich disqualifiert, auch wenn es wahrscheinlich nicht aus boshafter Absicht geschieht, sondern nur die OAuth-Rechtekonfiguration fahrlässig grob eingestellt ist. Ein Anfrage an den drone.io-Support deswegen ist noch unbeantwortet. [1] https://github.com/SpotlightKid/python-rtmidi Chris
Hast du mal bei Travis CI nachgefragt, ob man das nicht irgendwie Lösen kann? Oder geht das generell bei einer OpenVZ-Umgebung nicht? Könntest du die MIDI API für die Tests nicht irgendwie umbiegen / Nachbilden oder so? Mich würde allerdings auch Tests unter OS X und Windows interessieren. Wobei Travis CI support für OS X hat: http://docs.travis-ci.com/user/osx-ci-environment/ Am 29.06.2015 um 16:19 schrieb Christopher Arndt:
Hallo,
für eines meiner Open Source Python Projekte [1] will ich (lange überfällig) automatisiertes Testing und Building einführen.
Leider musste ich feststellen, das die übliche Lösung, Travis CI, für dieses Projekt nicht geeignet ist, weil die Tests das ALSA MIDI Sequencer Kernelmodul brauchen und man in den OpenVZ-Umgebungen von Travis keine Kernelmodule laden kann.
Welche Alternativen gibt es? Anforderungen: freier Plan für OS-Projekte, ALSA-Sequencer vorhanden oder ladbar und Zugriff auf Build-Artefakte, sprich Sdists, Eggs und Wheels. Idealerweise auch OS X und Windows Umgebungen.
drone.io hatte ich mir auch angeschaut und es sah auf den ersten Blick ganz gut aus. Als ich es jedoch ausprobieren wollte, sollte ich vollen (also Lese- *und Schreib*zugriff) auf mein Github-Profil erlauben. Das hat den Service für mich disqualifiert, auch wenn es wahrscheinlich nicht aus boshafter Absicht geschieht, sondern nur die OAuth-Rechtekonfiguration fahrlässig grob eingestellt ist. Ein Anfrage an den drone.io-Support deswegen ist noch unbeantwortet.
[1] https://github.com/SpotlightKid/python-rtmidi
Chris
_______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
-- Mfg. Jens Diemer ---- http://www.jensdiemer.de
Am 29.06.2015 um 16:34 schrieb Jens:
Hast du mal bei Travis CI nachgefragt, ob man das nicht irgendwie Lösen kann? Oder geht das generell bei einer OpenVZ-Umgebung nicht?
Geht generell nicht: https://github.com/travis-ci/travis-ci/issues/811#issuecomment-42281896
Könntest du die MIDI API für die Tests nicht irgendwie umbiegen / Nachbilden oder so?
Der Daseinszweck der python-rtmidi Library ist der Zugriff auf die jeweiligen MIDI-Frameworks der Betriebssysteme (i.e. ALSA, JACK, CoreMIDI und Winodws MM). Wenn ich diesen nicht testen kann, sind die Tests sinnlos. Chris
Am 29.06.2015 um 17:09 schrieb Christopher Arndt:
Am 29.06.2015 um 16:34 schrieb Jens:
Hast du mal bei Travis CI nachgefragt, ob man das nicht irgendwie Lösen kann? Oder geht das generell bei einer OpenVZ-Umgebung nicht?
Geht generell nicht:
https://github.com/travis-ci/travis-ci/issues/811#issuecomment-42281896
Bin gerade zufällig über "wercker" gestolpert: http://devcenter.wercker.com/quickstarts/building/python.html Nutzten wohl Docker...
Könntest du die MIDI API für die Tests nicht irgendwie umbiegen / Nachbilden oder so?
Der Daseinszweck der python-rtmidi Library ist der Zugriff auf die jeweiligen MIDI-Frameworks der Betriebssysteme (i.e. ALSA, JACK, CoreMIDI und Winodws MM). Wenn ich diesen nicht testen kann, sind die Tests sinnlos.
Das Leuchtet irgendwie ein ;) -- Mfg. Jens Diemer ---- http://www.jensdiemer.de
Am 29.06.2015 um 17:15 schrieb Jens:
Bin gerade zufällig über "wercker" gestolpert:
http://devcenter.wercker.com/quickstarts/building/python.html
Nutzten wohl Docker...
Danke, das schaue ich mir mal an. Da bei Docker aber m.W. auch der Kernel des Host-Systems benutzt wird, bin ich skeptisch... Ich würde mich über weitere Tipps und Erfahrungsberichte freuen. Chris
Am 29.06.2015 um 16:19 schrieb Christopher Arndt:
Hallo,
für eines meiner Open Source Python Projekte [1] will ich (lange überfällig) automatisiertes Testing und Building einführen.
Leider musste ich feststellen, das die übliche Lösung, Travis CI, für dieses Projekt nicht geeignet ist, weil die Tests das ALSA MIDI Sequencer Kernelmodul brauchen und man in den OpenVZ-Umgebungen von Travis keine Kernelmodule laden kann.
Vermutlich gibt es die Möglichkeit eine eigene Methode vor dem Test aufzurufen. Zu Not in setUp() deiner TestCase Klasse. In der Methode kannst du per zB subprocess.call("sudo ....") das Kernelmodul laden. Also ich denke nicht das aus diesem Grund Travis nicht geeignet ist. Sicherlich musst du dann Test dann auf einem eigenen Server laufen lassen. Ich vermute, dass kein freier Hoster dir das Laden von Kernelmodulen erlaubt. Oder den Kernel-Bereich per mock Bibliothek nur vorgaukeln. Aus akademischer Sichtweise ist das Testen der Zusammenarbeit zwischen Bibliothek und Kernel ein Integrationstest, kein Unittest. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Am 01.07.2015 um 08:00 schrieb Thomas Güttler:
Vermutlich gibt es die Möglichkeit eine eigene Methode vor dem Test aufzurufen. Zu Not in setUp() deiner TestCase Klasse.
Für Paketinstallations/Setupaufgaben gibt es bei Travis in der .travis.yml den 'before_install'-Abschnitt.
Also ich denke nicht das aus diesem Grund Travis nicht geeignet ist. [...] Ich vermute, dass kein freier Hoster dir das Laden von Kernelmodulen erlaubt.
Die beiden Sätze widersprechen sich etwas, meinst du nicht? Wie schon gesagt und durch den Link in den Bugtracker belegt, kann man in den OpenVZ-Umgebungen von Travis generell keine Kernelmodule laden, da bei dieser Virtualisierungslösung der Kernel des Hostsystems gemeinsam benutzt wird. Siehe dazu auch den Error-Log eines Builds: https://travis-ci.org/SpotlightKid/python-rtmidi/jobs/68403100
Oder den Kernel-Bereich per mock Bibliothek nur vorgaukeln.
Das bringt in diesem Fall leider nicht viel, da es sich bei python-rtmidi um Python-Bindings für eine C++-Bibliothek handelt. Die Tests sollen beweisen, dass der Aufruf der Methoden der C++-Klassen aus Python/Cython heraus, funkioniert und diese korrekt mit dem OS MIDI-Framework interagieren. Wenn ich die gewrappte C++-Bibliothek durch ein Mock ersetzen wollte, müsste das ganze Cython-Modul umgeschrieben werden und hätte dann nicht mehr viel mit dem Production-Code zu tun. Der Einsatzzweck der Bibliothek ist Discovery von MIDI-Schnittstellen und MIDI I/O über diese. Wenn ich diese nicht teste, habe ich durch die Tests wenig gewonnen.
Aus akademischer Sichtweise ist das Testen der Zusammenarbeit zwischen Bibliothek und Kernel ein Integrationstest, kein Unittest.
Ich habe auch nicht behauptet, dass ich nur Unittests machen will, schließlich heißt es ja auch Continuous *Integration*. Gruß, Chris
Am 01.07.2015 um 11:11 schrieb Christopher Arndt:
Am 01.07.2015 um 08:00 schrieb Thomas Güttler:
Vermutlich gibt es die Möglichkeit eine eigene Methode vor dem Test aufzurufen. Zu Not in setUp() deiner TestCase Klasse.
Für Paketinstallations/Setupaufgaben gibt es bei Travis in der .travis.yml den 'before_install'-Abschnitt.
Also ich denke nicht das aus diesem Grund Travis nicht geeignet ist. [...] Ich vermute, dass kein freier Hoster dir das Laden von Kernelmodulen erlaubt.
Die beiden Sätze widersprechen sich etwas, meinst du nicht?
Wieso? Travis ist laut dieser Tabelle als MIT-Lizenz verfügbar. Du müsstest den Travisserver eben selbst aufsetzen. Virtuelle root-Server kosten nicht mehr viel und haben auch andere Vorteile. https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
Wie schon gesagt und durch den Link in den Bugtracker belegt, kann man in den OpenVZ-Umgebungen von Travis generell keine Kernelmodule laden, da bei dieser Virtualisierungslösung der Kernel des Hostsystems gemeinsam benutzt wird.
Aber im Hypervisor (Hostsystem) kann man die Module laden.
Siehe dazu auch den Error-Log eines Builds:
https://travis-ci.org/SpotlightKid/python-rtmidi/jobs/68403100
Oder den Kernel-Bereich per mock Bibliothek nur vorgaukeln.
Das bringt in diesem Fall leider nicht viel, da es sich bei python-rtmidi um Python-Bindings für eine C++-Bibliothek handelt. Die Tests sollen beweisen, dass der Aufruf der Methoden der C++-Klassen aus Python/Cython heraus, funkioniert und diese korrekt mit dem OS MIDI-Framework interagieren. Wenn ich die gewrappte C++-Bibliothek durch ein Mock ersetzen wollte, müsste das ganze Cython-Modul umgeschrieben werden und hätte dann nicht mehr viel mit dem Production-Code zu tun.
Der Einsatzzweck der Bibliothek ist Discovery von MIDI-Schnittstellen und MIDI I/O über diese. Wenn ich diese nicht teste, habe ich durch die Tests wenig gewonnen.
ok, ich verstehe.
Aus akademischer Sichtweise ist das Testen der Zusammenarbeit zwischen Bibliothek und Kernel ein Integrationstest, kein Unittest.
Ich habe auch nicht behauptet, dass ich nur Unittests machen will, schließlich heißt es ja auch Continuous *Integration*.
Alles prima. Das hatte ich nur im Plauderton dazu geschrieben. Sorry, wenn das bei dir als Kritik oder so ähnlich ankam. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Am 03.07.2015 um 12:13 schrieb Thomas Güttler:
Travis ist laut dieser Tabelle als MIT-Lizenz verfügbar. Du müsstest den Travisserver eben selbst aufsetzen. Virtuelle root-Server kosten nicht mehr viel und haben auch andere Vorteile.
Ok, sorry, ich dachte, du redest von Travis als Service, nicht als Software-Lösung. Eine eigene VM habe ich, wollte aber eigentlich den Aufwand vermeiden, einen eigenen CI-Server aufzusetzen. Erstens, weil öffentliche Services wie Travis es einfacher machen, für Contributors und Forks das gleiche CI-Setup zu nutzen, zweitens weil ich für Windows und OS X VMs nicht die notwendige Hardware habe. Anscheinend komme ich aber wohl nicht daran vorbei. Dann würde es aber wohl keine Jenkins-basierte Lösung werden, Java-Zeugs würde den knappen Speicher meiner VM vermutlich über Gebühr beanspruchen. Chris
Am 03.07.2015 um 13:23 schrieb Christopher Arndt:
Anscheinend komme ich aber wohl nicht daran vorbei. Dann würde es aber wohl keine Jenkins-basierte Lösung werden, Java-Zeugs würde den knappen Speicher meiner VM vermutlich über Gebühr beanspruchen.
Vielleicht kommt https://uberspace.de/ statt VM in Frage? Mfg. Jens
participants (3)
-
Christopher Arndt -
Jens -
Thomas Güttler