apache/spamassassinOpen-Source-Framework zur E-Mail-Filterung, das Spam und Phishing mithilfe von Inhaltsanalyse, Header-Prüfungen, Bayes-Scoring und DNS-Blocklisten erkennt.
Das Apache SpamAssassin-Projekt verwendet für seinen Entwicklungsprozess ein Subversion-Repo. Ein schreibgeschützter Spiegel des Repos wird auf GitHub hier gepflegt.
Das .github-Verzeichnis, das diese README-Datei enthält, ist nicht Teil des Apache-SpamAssassin-Releasepakets. Die Dateien in diesem Verzeichnis sind für Entwickler gedacht, um Tests mithilfe der GitHub-Actions-Funktion auf von GitHub gehosteten Runnern auszuführen.
Das Projektmanagement-Komitee von Apache SpamAssassin hat keine Vorkehrungen getroffen, um die von GitHub der Apache Software Foundation zugewiesenen Ressourcen für Builds und Tests zu nutzen. Die in diesem Verzeichnis definierten Aktionen stehen allen, einschließlich aktiver Entwickler von SpamAssassin, zur Verfügung, um sie in ihrem persönlichen GitHub-Fork des Repos auszuführen. Die Aufnahme der Dateien in dieses Repository stellt jedoch keine formelle Veröffentlichung der Software für die Öffentlichkeit dar.
Der Workflow-Lauf, den Sie übermitteln, enthält einen Job für jede gültige Kombination von Werten aus den ersten drei Eingabefeldern.
Im vierten Eingabefeld können Sie die auszuführenden Tests im gleichen Format eingeben, das für TEST_FILES in einer make-test-Befehlszeile verwendet wird. Wenn es leer gelassen wird, bedeutet das, dass alle Tests ausgeführt werden.
Unabhängig davon, was in das Testfeld eingegeben wird, werden die Tests, die SQL verwenden, nur in den Jobs ausgeführt, in denen postgres oder mysql als Datenbank angegeben ist. Außerdem werden die spamd-Stresstests und Root-Tests nie ausgeführt.
GitHub hat Begrenzungen für die Anzahl der Jobs, die Sie gleichzeitig auf den verschiedenen Plattformen ausführen können. Jobs, die Sie über dieses Limit hinaus einreichen, werden in die Warteschlange gestellt und gestartet, sobald andere Jobs abgeschlossen sind.
Ein Klick auf einen in der linken Seitenleiste aufgeführten Job öffnet einen Bereich mit der Protokollausgabe des Jobs. Ein Job, der mit Fehlern endet, hat ein rotes X-Symbol. Sie können die Protokollausgabe auf Details prüfen. Bei manchen Fehlern wird der Inhalt des Verzeichnisses t/log als Artefakt gezippt, das Sie herunterladen können. Wenn Sie den Protokollbereich anzeigen, klicken Sie auf das Summary-Symbol über der linken Seitenleiste. Falls Artefakte zum Herunterladen vorhanden sind, gibt es unter der Überschrift Artifacts eine Nummer, auf die Sie klicken können.
Die Anzahl der ausgeführten Jobs ist das Produkt der Optionen, die Sie in den drei Eingabefeldern angeben. Sofern Sie SpamAssassin nicht auf jeder möglichen perl-Version testen möchten – was Sie vielleicht tun, wenn Sie der Release-Manager sind und ein neues Release vorbereiten –, sollten Sie wahrscheinlich nur eine aktuelle perl-Version auswählen.
Das Optionsfeld für Runner zeigt nur die „-latest“-Namen, Sie können jedoch jeden von GitHub bereitgestellten gehosteten Runner eingeben, z. B. ubuntu-20.04 oder macos-11.
Windows wird mit Strawberry Perl getestet, dessen neueste Version 5.32 ist. Wenn Sie 34 oder 36 in der perl-Versionsliste haben, werden diese auf der Windows-Plattform keine Jobs erzeugen.
Jobs, die mit der Datenbankoption postgres oder mysql ausgeführt werden, führen nur die verschiedenen SQL-Tests aus. Jobs, die mit der Option none für die Datenbank ausgeführt werden, führen alle anderen Tests aus.
Einige Tests, insbesondere solche, die auf Netzwerkzugriff angewiesen sind, wie t/dnsbl.t, scheinen gelegentlich fehlzuschlagen, besonders wenn Sie viele Jobs gleichzeitig ausführen. Nachdem alle Jobs eines Workflows abgeschlossen sind, können Sie nur die fehlgeschlagenen erneut ausführen, indem Sie auf der Übersichtsseite für die Jobs auf die Schaltfläche Re-run jobs klicken und dann Re-run failed jobs auswählen. Wiederholen Sie dies, bis Jobs, die nur gelegentliche Fehlschläge zu sein scheinen, erfolgreich bestanden haben.
