MEP19: Kontinuierliche Integration #

Status #

Abgeschlossen

Branches und Pull-Requests #

Zusammenfassung #

matplotlib könnte von einer besseren und zuverlässigeren kontinuierlichen Integration profitieren, sowohl zum Testen als auch zum Erstellen von Installationsprogrammen und Dokumentation.

Detaillierte Beschreibung #

Aktueller Stand der Technik #

Testen

matplotlib verwendet derzeit Travis-CI für automatisierte Tests. Während Travis-CI dafür gelobt werden sollte, wie viel es als kostenloser Dienst tut, hat es eine Reihe von Mängeln:

  • Es schlägt oft aufgrund von Netzwerk-Timeouts beim Installieren von Abhängigkeiten fehl.

  • Es scheitert oft aus unerklärlichen Gründen.

  • Build- oder Testprodukte können nur vor dem Build-Off von Branches im Hauptrepo gespeichert werden, nicht bei Pull-Requests, daher ist es oft schwierig, "post mortem" zu analysieren, was schief gelaufen ist. Dies ist besonders ärgerlich, wenn der Fehler nachträglich nicht lokal reproduziert werden kann.

  • Es ist nicht extrem schnell. Die CPU- und Speicheranforderungen von matplotlib zum Testen sind viel höher als bei einem durchschnittlichen Python-Projekt.

  • Es wird nur unter Ubuntu Linux getestet, und wir haben nur minimale Kontrolle über die Besonderheiten der Plattform. Es kann jederzeit außerhalb unserer Kontrolle aktualisiert werden, was zu unerwarteten Verzögerungen zu Zeiten führt, die in unserem Veröffentlichungsplan möglicherweise nicht günstig sind.

Auf der positiven Seite ist die Integration von Travis-CI mit github – automatisches Testen aller ausstehenden Pull-Requests – außergewöhnlich.

Baut

There is no centralized effort for automated binary builds for matplotlib. However, the following disparate things are being done [If the authors mentioned here could fill in detail, that would be great!]:

  • @sandrotosi: builds Debian packages

  • @takluyver: Has automated Ubuntu builds on Launchpad

  • @cgohlke: Makes Windows builds (don't know how automated that is)

  • @r-owen: Makes OS-X builds (don't know how automated that is)

Documentation

Documentation of main is now built by travis and uploaded to https://matplotlib.org/devdocs/index.html

@NelleV, I believe, generates the docs automatically and posts them on the web to chart MEP10 progress.

Peculiarities of matplotlib#

matplotlib has complex requirements that make testing and building more taxing than many other Python projects.

  • Die CPU-Zeit zum Ausführen der Tests ist ziemlich hoch. Es bringt uns über die kostenlosen Konten vieler CI-Dienste (z. B. ShiningPanda) hinaus.

  • Es hat eine große Anzahl von Abhängigkeiten, und das Testen der vollständigen Matrix aller Kombinationen ist unpraktisch. Wir müssen schlau sein, welchen Raum wir testen und garantieren, dass er unterstützt wird.

Anforderungen #

Dieser Abschnitt beschreibt die Anforderungen, die wir haben möchten.

  1. Testen aller Pull-Requests durch Einbinden in die GitHub-API, wie es Travis-CI tut

  2. Testen auf allen wichtigen Plattformen: Linux, Mac OS-X, MS Windows (in dieser Prioritätsreihenfolge, basierend auf einer Benutzerumfrage)

  3. Bewahren Sie die Build- und Testprodukte der letzten n Tage auf, um das Post-Mortem-Debugging zu unterstützen.

  4. Automatisierte nächtliche Binär-Builds, damit Benutzer die neuesten Entwicklungen testen können, ohne eine vollständige Kompilierungsumgebung zu installieren.

  5. Automatisiertes Benchmarking. Es wäre schön, eine Standard-Benchmark-Suite (getrennt von den Tests) zu haben, deren Leistung im Laufe der Zeit in verschiedenen Backends und Plattformen verfolgt werden könnte. Obwohl dies vom Erstellen und Testen getrennt ist, würde es idealerweise auf derselben Infrastruktur ausgeführt.

  6. Automatisiertes nächtliches Erstellen und Veröffentlichen von Dokumentation (oder als Teil von Tests, um sicherzustellen, dass PRs keine Dokumentationsfehler einführen). (Dies würde standardmäßig nicht die statische Dokumentation für stabile Versionen ersetzen).

  7. Die Testsysteme sollten von mehreren Entwicklern beherrschbar sein, damit keine einzelne Person zum Flaschenhals wird. (Das Design von Travis-CI macht das gut – das Speichern der Build-Konfiguration im Git-Repository und nicht anderswo ist ein sehr gutes Design.)

  8. Machen Sie es einfach, eine große, aber spärliche Matrix verschiedener Versionen der Abhängigkeiten von matplotlib zu testen. Die Matplotlib-Benutzerumfrage liefert einige gute Daten darüber, worauf wir unsere Bemühungen konzentrieren sollten: https://docs.google.com/spreadsheets/d/1jbK0J4cIkyBNncnS-gP7pINSliNy9lI-N4JHwxlNSXE/edit

  9. Schön zu haben: Ein dezentrales Design, damit Benutzer mit eher undurchsichtigen Plattformen Build-Ergebnisse in einem zentralen Dashboard veröffentlichen können.

Implementierung #

Dieser Teil muss noch geschrieben werden.

Idealerweise wäre die Implementierung jedoch ein Dienst eines Drittanbieters, um zu vermeiden, dass wir unsere ohnehin schon lange Zeit mit der Systemadministration belasten. Da wir einige Spendengelder haben, kann dieser Service kostenpflichtig sein, wenn er erhebliche zeitsparende Vorteile gegenüber kostenlosen Angeboten bietet.

Abwärtskompatibilität #

Abwärtskompatibilität ist für diesen Abgeordneten kein großes Anliegen. Wir werden aktuelle Tools und Verfahren durch etwas Besseres ersetzen und die alten über Bord werfen.

Alternativen #

Hangout-Notizen #

CI-Infrastruktur #

  • Wir mögen Travis und es wird wahrscheinlich auf jeden Fall Teil unseres Arsenals bleiben. Die Zuverlässigkeitsprobleme werden untersucht.

  • Aktivieren Sie Amazon S3-Uploads von Testprodukten auf Travis. Dies wird bei der Post-Mortem-Analyse von Fehlern helfen (@mdboom untersucht dies jetzt).

  • Wir wollen Mac-Abdeckung. Am besten drängen Sie Travis, es für unser Projekt zu aktivieren, indem Sie sie für ein Pro-Konto bezahlen (da sie ansonsten keine Tests sowohl auf Linux als auch auf Mac zulassen).

  • Wir wollen Windows-Abdeckung. Shining Panda ist dort eine Option.

  • Suchen Sie nach einem Tool, das Testergebnisse aus einer Reihe von Quellen sammelt und synthetisiert, und posten Sie es mithilfe der GitHub-API auf GitHub. Dies kann für die Scipy-Community von allgemeinem Nutzen sein.

  • Sowohl für Windows als auch für Mac sollten wir den Prozess des Einrichtens der Maschine für einen Build und das Erstellen von Binärdateien und Installationsprogrammen dokumentieren (oder noch besser skripten). Dazu kann es erforderlich sein, Informationen von Russel Owen und Christoph Gohlke einzuholen. Dies ist ein notwendiger Schritt für automatisierte Builds, wäre aber auch aus einer Reihe anderer Gründe wertvoll.

Das Testframework selbst #

  • Wir sollten nach Wegen suchen, damit es weniger Zeit in Anspruch nimmt

    • Eliminieren Sie redundante Tests, wenn möglich

    • Allgemeine Leistungsverbesserungen für matplotlib werden helfen

  • Wir sollten mehr Dinge abdecken, insbesondere mehr Backends

  • Wir sollten mehr Unit-Tests haben, weniger Integrationstests, wenn möglich