Etherpad-lite: Datenbankunterstützungstests in Travis-CI und DockerHub hinzufügen

Hallo @madmath03 , es ist beruhigend zu sehen, dass sich all die Arbeit, die wir geleistet haben, um Etherpad Docker-freundlicher zu machen (#3542 und 6d9264cf3cd7 von @pierreprinetti), auszahlt.

Ich könnte versuchen, eine PN dafür zu schicken, wenn das für dich interessant ist und ich die Zeit finde

Das wäre wunderbar! Wir können nur von mehr automatisierten Tests profitieren.

Ich sehe, dass Ihre Dockerfiles (zum Beispiel dieses im Entwicklungszweig ) genug WRT-Upstream modifiziert sind.

@pierreprinetti , wären Sie bereit, mit @madmath03 zusammenzuarbeiten , um dies zu erreichen?

Wärst du bereit, mit zu arbeiten?

Absolut. Danke @madmath03 für die Initiative!

Planung für 1.8.4 (1.8.3 wird in ~Tagen veröffentlicht).

FWIW Ich baue auch Travis-Testing in UeberDB ein und modernisiere das Projekt hoffentlich ein wenig. Ich hoffe, dies innerhalb von 7 Tagen zu landen.

Es ist gelandet und wartet auf Mux, um es zu überprüfen :)

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität hatte. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

Vielleicht sollte diesem Problem ein Tag hinzugefügt werden, um dies nicht zu schließen, da #3855 dies beantwortet.

Ich werde einfach einen Sledgejammer benutzen und meine Arbeit zusammenführen. Es steht lange genug zur Überprüfung und hat 0 Feedback erhalten.

@JohnMcLear warum wurde das geschlossen? Ich verstehe, dass Sie Tests in UeberDB hinzugefügt haben, aber das bedeutet nicht, dass Etherpad keine Datenbanken testen sollte, oder habe ich etwas übersehen?

Ich bin zufrieden genug mit den Tests, die in ether/ueberdb travis laufen.

1. Wir haben eine vollständige Integration für ueber bis hin zum Frontend (wenn auch exklusiv für dirty db).
2. Wir haben Lasttests sowohl in ueberdb repo (für alle Datenbanken) als auch in ether/etherpad-lite (wieder exklusiv für dirty)
3. Die Testabdeckung kann zu umständlich werden und zu lange dauern, wenn Sie die X-Datenbank auf dem Y-Betriebssystem im Z-Browser testen. Wir machen bereits Y OS und Z Browser.
4. Es ist mehr Code zu schreiben/zu pflegen, den das ueberdb-Repository meiner Meinung nach vollständig abdeckt und handhabt. Wir würden viel Aufwand verdoppeln.
5. Es macht nur wirklich Sinn, diese Tests zu implementieren, wenn Sie viele Daten einschließen, um eine echte Instanz zu simulieren (ueberdb macht dies für MySQL). Auch dies bläst das Projekt noch weiter auf.

Obwohl diese Testabdeckung eine nette Sache sein könnte, denke ich, dass die Kosten für den Code und die Zeit für die Ausführung der Tests nicht wirklich erforderlich sind und die Gesamtauswirkung auf das Projekt negativ sein wird.

Das heißt, wenn jemand die Travis- und Testrunner-Logik schreibt und diesen Code gerne beibehält, würde ich mich freuen, wenn er zusammengeführt wird :)

Mein Punkt läuft darauf hinaus, dass wir darauf vertrauen können, dass die Tests von ueberdb über Etherpad reflektieren.