Ich lade Sie ein, Gedanken über mögliche CI-Workflows zu teilen, die Tests für von der Community bereitgestellte inoffizielle Plugins ausführen würden.
Einige Communities sind stark auf Plugins angewiesen, ohne etablierte Wartung:
Da das Testen von Plugins eine Discourse-Installation als Testumgebung erfordert, frage ich mich, wie ein Community-gestützter CI-Workflow aussehen könnte.
Einige Plugins enthalten Specs, wie Angus’ Implementierung von activitypub, die, soweit ich weiß, Tests für CI ermöglichen.
Derzeit denke ich über zwei mögliche Wege nach, um das Testen von inoffiziellen Plugins zu verbessern, abhängig von den Specs / Tests, die in der Plugin-Quelle enthalten sind:
a) eine Maschinerie zu bauen, die Website-Maintainern hilft, Tests in einer Staging-Umgebung auszuführen
b) einen Dienst zu haben, der ein vordefiniertes Test-Image forkt, um Tests für den letzten veröffentlichten Code des Plugins zu melden.
Zusätzlich zu CI mit Backend- und Frontend-Tests, was die meisten Pavilion-Plugins jetzt haben, verfügen wir über ein Plugin-Manager-System, dessen Teil CI ist. So funktioniert es
Dies zeigt den Status der Überprüfungen auf Kompatibilität von Pavilion-Plugins (und manchmal auch anderen) mit tests-passed und stable. Dies wird täglich automatisch aktualisiert.
Dies beruht natürlich auf Tests, einschließlich Smoke-Tests, Specs (Backend) und QUnit-Tests (Frontend).
Unser Abonnement-Plugin (Custom Wizard) hat die höchste Testabdeckung, wie Sie sich vorstellen können, aber einige unserer kostenlosen Plugins enthalten eine gute Suite von Backend- und Frontend-Tests (z. B. Locations).
Das Schreiben von Tests ist eine gute Praxis, und Pavilion ist in diesem Bereich sicherlich noch disziplinierter geworden, da wir uns als Unternehmen weiterentwickelt haben.
Entscheidend ist, dass Tests auch Ihre beabsichtigte Funktionalität dokumentieren, was besonders wichtig ist bei Kompatibilitätsaktualisierungen oder Refactoring.
Es ist eine Architektur gemäß @angus’ Diagramm, mit mehreren beteiligten Repositories, aber dies ist der Status-Server:
Es ist auch ein Ansatz:
Implementieren Sie niemals eine Korrektur, ohne nach einem Test zu suchen, und wenn kein geeigneter Test existiert, fügen Sie einen hinzu.
Entwickeln Sie vorzugsweise zuerst den Test, zeigen Sie, dass er fehlschlägt, beheben Sie dann das Problem und bestätigen Sie, dass Ihr neuer Test erfolgreich ist.
Auf diese Weise baut Ihre Abdeckung im Laufe der Zeit auf …
Darüber hinaus:
Das Nachrüsten von Tests kann riskant sein, da Sie möglicherweise falsch interpretieren, was der Code beabsichtigt hat … besser als gar nichts zu tun …
Alle offiziellen Plugins haben Spezifikationen, die Sie als Beispiele verwenden können. Das Plugin discourse-plugin-Skelton enthält GitHub Actions, um Tests bei jedem Commit und, wie ich glaube, täglich auszuführen.
a) Dies ist über GitHub Actions verfügbar: Plugins mit ordnungsgemäßen Spezifikationen / Tests mit GitHub Actions erhalten einen Badge auf GitHub, wenn alle Tests bestanden sind und der Status von CI-Aktionen von der API gelesen werden kann.
b) Abgesehen von offiziellen Discourse-Plugins und Pavilion-Plugins gibt es keine automatische Übersicht für Administratoren, ob verwendete Plugins in der für das Update vorgesehenen Version funktionieren werden?
Soweit ich das verstehe, ist dies eine Lösung für das umgekehrte Problem: Discourse zu alt für ein Plugin.
Wie behandelt man den umgekehrten Fall: Plugin zu alt für Discourse?
Könnte /admin/upgrade vor Plugins warnen, die für ein beabsichtigtes Upgrade fehlschlagen?
Wir haben ursprünglich eine unbranded Version unseres Plugin-Dashboards erstellt und bereitgestellt, in der Drittanbieter-Autoren ihre Plugins zur Aufnahme anbieten konnten. Dies fand wenig Anklang, teilweise weil die Population von Drittanbieter-Plugin-Entwicklern sehr klein ist.
Die Erstellung von Drittanbieter-Discourse-Plugins ist ziemlich nischig und Drittanbieter, die Plugins mit guter Testabdeckung bereitstellen, sind sehr nischig!
Viele der Freiberufler in diesem Bereich sind entweder Pavilion oder CDCK beigetreten (oder im Laufe der Zeit beiden!).
Daher haben wir uns schließlich entschieden, unser Dashboard einfach in unsere gebrandete Community-Website zu integrieren.
