Was ist Mattermost?

Von ihrer Website:

Mattermost is a flexible, open source messaging platform
that enables secure team collaboration

Stell dir Mattermost also als Open-Source-Alternative zu Slack vor. Es ist außerdem bei On-Premise-Installationen von GitLab Omnibus mit dabei.

Was möchte ich erreichen?

Beim Versuch, an Hacktoberfest 2019 teilzunehmen, habe ich mir ein Migrations-Issue für Mattermost als erstes Ziel für einen PR ausgesucht:

Migrate tests from “model/system_test.go” to use testify

Worum geht es in diesem Beitrag

In diesem Beitrag geht es um meine Erfahrung beim Beitragen (oder Scheitern daran) zu Mattermost.

Beitragen

Kontakt aufnehmen

Nachdem ich das Issue gefunden hatte, an dem ich arbeiten wollte, bin ich dem Mattermost-Build-Server beigetreten und habe per Kommentar am Issue darum gebeten, zugewiesen zu werden. Die Antwort kam schnell, und dadurch fühlte ich mich schon willkommen.

Einrichtung

Ich habe begonnen, die Entwicklungsumgebung gemäß dem Artikel Developer Setup -> ArchLinux einzurichten. Das ist recht unkompliziert und funktioniert wie beschrieben.

Um mein Setup zu testen, wollte ich die vorhandenen Tests als Ausgangsbasis ausführen. Leider klappte das nicht auf Anhieb:

go: willnorris.com/go/imageproxy@v0.9.0 requires
    cloud.google.com/go@v0.37.1 requires
    go.opencensus.io@v0.19.1 requires
    google.golang.org/genproto@v0.0.0-20181219182458-5a97ab628bfb requires
    google.golang.org/grpc@v1.16.0 requires
    github.com/golang/lint@v0.0.0-20190227174305-8f45f776aaf1: invalid pseudo-version: does not match version-control timestamp     (2018-12-17T17:45:47Z)

Tatsächlich ist das kein Fehler in Mattermosts Codebasis, sondern in der Art, wie Go 1.13 die Zeitstempel-Validierung in Go-Modulen handhabt. Vorübergehend auf Go 1.12 zurückzuwechseln hat mir also geholfen. Zum Glück deploye ich Go auf meinem Rechner mit Ansible über eine eigene Rolle, und ein Wechsel zwischen Go-Versionen ist eine Sache eines kleinen Playbook-Laufs.

Alle Tests auszuführen dauert eine Weile, und es stellte sich heraus, dass die komplette Suite mit einem Developer-Setup nur für den Server nicht durchläuft.

Da mein Beitrag das model-Paket betrifft, bin ich in das Unterverzeichnis model gewechselt und habe go test ./... -v ausgeführt:

=== RUN   TestAccessJson
--- PASS: TestAccessJson (0.00s)
=== RUN   TestAccessIsValid
--- PASS: TestAccessIsValid (0.00s)
=== RUN   TestAnalyticsRowJson
--- PASS: TestAnalyticsRowJson (0.00s)
=== RUN   TestAnalyticsRowsJson

...

--- PASS: TestConfigDefaults (0.01s)
    --- PASS: TestConfigDefaults/somewhere_nil_when_uninitialized (0.00s)
        utils_test.go:725: config.ServiceSettings.SiteURL was nil
    --- PASS: TestConfigDefaults/nowhere_nil_when_initialized (0.00s)
    --- PASS: TestConfigDefaults/nowhere_nil_when_partially_initialized (0.01s)
PASS
ok      github.com/mattermost/mattermost-server/model   (cached)
?       github.com/mattermost/mattermost-server/model/gitlab    [no test files]

Ab jetzt hatte ich eine valide Grundlage für meine Implementierung.

Implementierung

Die erste Implementierung ging leicht von der Hand: drei Zeilen entfernen, zwei hinzufügen. Statt so:

if result.Name != "test" {
  t.Fatal("Ids do not match")
}

sieht der Code nun so aus (zum Zeitpunkt des Schreibens):

require.Equal(t, "test", result.Name, "ids do not match")

Und siehe da: Die Tests liefen weiterhin durch! Um zu prüfen, ob sie fehlschlagen, habe ich vorübergehend mit test2 verglichen, und es schlug erwartungsgemäß fehl.

Pull Request!

Nachdem der Test weiterhin funktionierte, habe ich einen PR erstellt, um meine Änderungen in Mattermost zu integrieren.

Nach den Reviews wurde mein PR gemergt, und ich habe daran mitgewirkt, eine Open-Source-Software ein kleines bisschen besser zu machen.