Build aus dem Quellcode

Diese Seite erklärt, wie Sie Antimatter aus dem Quellcode bauen und ausführen, um daran zu arbeiten oder eigene Builds zu erstellen. Sie behandelt den Server und die Web-Oberflächen, die in einem Repository liegen, sowie das Docker-Image und die Apps.

Voraussetzungen

Los, in der Version in server/go.mod (1.26.7 zum Zeitpunkt der Erstellung).
Node.js und npm in den Versionen aus .nvmrc und webapp/package.json (Node 24.11.1 mit npm 11.6.2). Mit mise installiert die mise.toml des Repositories die passende Node-Version.
Docker mit Compose: Das Entwicklungssetup führt PostgreSQL und einige weitere Dienste in Containern aus.
make, git und ein Linux- oder macOS-System.
Arbeitsspeicher: Das Bauen der Web-Oberflächen ist der aufwendigste Teil. Planen Sie 16 GB RAM ein; siehe Builds und Arbeitsspeicher.

git clone https://github.com/AntimatterChat/antimatter.git
cd antimatter

Das Repository enthält den Server in server/, die Web-Oberflächen in webapp/ (Fusion in webapp/fusion, Classic in webapp/channels, gemeinsame Pakete in webapp/platform) sowie End-to-End-Tests in e2e-tests/.

Entwicklungsserver starten

cd server
make run

make run startet die Entwicklungscontainer (PostgreSQL, Redis, ein Mail-Catcher und Monitoring-Tools), verknüpft die Web-App-Builds an der richtigen Stelle, startet den Server im Hintergrund mit go run und startet den Watcher der Web-App, der die Classic-Oberfläche beim Bearbeiten neu baut. Öffnen Sie http://localhost:8065 und erstellen Sie ein Konto: Das erste wird zum System-Administrator.

Befehl (in `server/`)	Funktion
`make run-server`, `make run-client`	Nur den Server oder nur den Web-App-Watcher starten.
`make restart-server`	Den Server nach Änderungen am Go-Code neu starten.
`make stop`	Server, Watcher und Container stoppen.
`make debug-server`	Den Server unter dem Delve-Debugger ausführen.
`make run-cli ARGS="-version"`	Einen Serverbefehl ausführen.
`make config-reset`	`config/config.json` auf die Standardwerte zurücksetzen.
`make clean`, `make nuke`	Build-Dateien entfernen; `nuke` löscht zusätzlich die Entwicklungsdaten.

Die Entwicklungsdatenbank ist postgres://mmuser:mostest_password@localhost/mattermost_test, die Standard-Datenquelle des Servers. Wählen Sie mit ENABLED_DOCKER_SERVICES aus, welche Container gestartet werden, in einer server/config.override.mk-Datei oder in Ihrer Umgebung (siehe server/config.mk).

Die Web-Oberflächen

In webapp/:

npm install      # also builds the shared packages
npm run build    # the classic interface, then Fusion

Die Builds landen in webapp/channels/dist (klassisch) und webapp/fusion/dist (Fusion). make client in server/ verknüpft sie als server/client und server/client-fusion, wo der Server sie bereitstellt: klassisch unter /static/, Fusion unter /static/fusion/.

npm run run (oder make run in webapp/) überwacht und baut die klassische Oberfläche neu. Fügen Sie WATCH_FUSION=true hinzu, um auch Fusion neu zu bauen.
npm run dev-server (make dev) führt stattdessen den Entwicklungsserver von Webpack aus: klassisch auf Port 9005, Fusion auf Port 9006.
Um eine der beiden Oberflächen im Browser anzuzeigen, fügen Sie ?webui=fusion oder ?webui=classic an die Adresse jeder Seite hinzu.

Tests und Prüfungen

Befehl	Wo	Funktion
`make test-server`	`server/`	Die Test-Suite des Servers, gegen die Entwicklungsumgebungen. Dies dauert lange.
`make test-server-quick`	`server/`	Nur die kurzen Tests.
`go test ./channels/app/... -run TestName`	`server/`	Ein Paket oder ein Test, mit laufenden Containern (`make start-docker`).
`make check-style`	`server/`	go vet, golangci-lint und die anderen Go-Prüfungen.
`make test`	`webapp/`	Die Unit-Tests der Web-App (Jest), in jedem Paket.
`npm run test -- <pattern>`	`webapp/fusion`	Einige der Tests von Fusion.
`make check-style`, `make check-types`	`webapp/`	ESLint und TypeScript.
`make i18n-extract`	`server/` und `webapp/`	Aktualisiert die englischen String-Dateien, nachdem Sie Strings hinzugefügt oder geändert haben (siehe Übersetzungen).

Führen Sie make modules-tidy aus, anstatt go mod tidy in server/.

Release-Archive

cd webapp && npm run build && cd ..
cd server
make build-linux       # the antimatter and amctl binaries
make package-linux     # dist/antimatter-linux-amd64.tar.gz and -arm64

make build erstellt die Web-Oberflächen und die Linux-Binaries in einem Schritt. Das Archiv enthält bin/antimatter, bin/amctl, eine Standard-config/config.json mit einer README.md zur Änderung der Einstellungen, beide Web-Oberflächen, die Vorlagen, die Schriftarten und die Übersetzungen. Andere Plattformen: make package-osx, make package-windows, make package-freebsd.

Mitgelieferte Apps

Ein einfaches make package-linux erstellt ein Archiv ohne Apps. Um diese einzubinden, wie es die veröffentlichten Releases tun, laden Sie zuerst die signierten App-Bundles herunter und übergeben deren Ordner:

build/package/fetch-apps.sh "$HOME/release-apps"   # needs gh, python3 and gpg
make package-linux PREPACKAGED_PLUGINS_DIR="$HOME/release-apps"

fetch-apps.sh lädt die neueste GitHub-Version jeder in plugins.json von antimatter-docker aufgeführten App zusammen mit ihrer Signatur herunter und prüft diese gegen den Plugin-Schlüssel von Antimatter. Standardmäßig werden Whiteboard, Sprachkanäle, Anrufe, KI-Chat (Agenten), Zu erledigen, Umfragen, Notizen, GIFs und Memes geladen; AM_BUNDLED_APPS (Repository-Namen, durch Leerzeichen getrennt) ändert diese Liste. Apps ohne Version oder ohne Signatur werden mit einer Warnung übersprungen. Die Pakete landen im Ordner prepackaged_plugins/ des Archivs.

.deb- und .rpm-Pakete

build/package/build-packages.sh <archive> <amd64|arm64> <version> <out-dir> wandelt ein Release-Archiv in All-in-One-.deb- und .rpm-Pakete um, mit nfpm. Der Administrator-Leitfaden beschreibt, was diese installieren: siehe .deb- oder .rpm-Paket installieren.

Der Release-Workflow

Der Workflow antimatter-release.yml im Server-Repositorium erledigt all dies auf GitHub: Bei einem v*-Tag erstellt er die Archive und Pakete für amd64 und arm64, mit SHA256SUMS, und veröffentlicht sie als GitHub-Release des Tags (ein Pre-Release für Versionen mit einem -). Bei manueller Ausführung nummeriert er den Build als 0.9.0-dev.<run> und speichert die Dateien als Workflow-Artefakte. Jedes App-Repositorium hat einen release.yml-Workflow, der sein signiertes Bundle auf dieselbe Weise veröffentlicht.

Das Docker-Image

Das antimatter-docker-Repository baut die veröffentlichten Images, den Server mit seinen Apps, vollständig innerhalb von Docker:

git clone https://github.com/AntimatterChat/antimatter-docker.git
cd antimatter-docker
scripts/build-all.sh                     # from the main branches on GitHub
SOURCES=local scripts/build-all.sh       # from your checkouts next to this folder
VARIANT=next scripts/build-all.sh        # the "next" image, with every Antimatter app

Dafür werden Docker mit buildx, Python 3, git und gpg, etwa 16 GB RAM und 30 GB Festplattenspeicher benötigt. Das Ergebnis wird als ghcr.io/antimatterchat/antimatter:dev geladen; testen Sie es mit ANTIMATTER_IMAGE=ghcr.io/antimatterchat/antimatter:dev docker compose -f compose.local.yml up -d. plugins.json listet die Apps und die gebauten Versionen auf, und das README des Repositories erklärt die Varianten.

build-all.sh signiert die mitgelieferten Apps mit dem Antimatter-Signierungsschlüssel, und der Image-Build lehnt Apps ohne Signatur ab. Ohne diesen privaten Schlüssel, der nur den Maintainer zur Verfügung steht, führen Sie die ersten Schritte einzeln aus: scripts/fetch-sources.sh, scripts/build-plugins.sh (App-Bundles in out/plugins/) und scripts/build-server.sh (Server-Archive in out/server/).

Builds und Speicher

Die Web-Oberflächen sind große Webpack-Builds, und ein Speichermangel ist die häufigste Ursache für Build-Fehler.

npm run build erstellt die klassische Oberfläche und Fusion nacheinander, nicht gleichzeitig, um den Speicherbedarf zu begrenzen. Führen Sie sie nicht parallel aus.
Der Minifier startet einen Worker pro Prozessor. Auf einem System mit vielen Kernen, aber wenig Speicher, begrenzen Sie die Prozessoren, die der Build sieht: taskset -c 0-5 npm run build.
Falls Node den Heap-Speicher erschöpft, erhöhen Sie das Limit: NODE_OPTIONS=--max-old-space-size=6144. Der Docker-Build verwendet diesen Wert (BUILD_NODE_OPTIONS in build.env).
Vermeiden Sie es, die vollständige Test-Suite des Servers, einen Web-Build und einen Docker-Build gleichzeitig auf einem kleinen System auszuführen.

Die Apps

Jede App (Plugin) hat ihr eigenes Repository und ihre eigene Makefile; make dist erstellt das Bundle. Siehe Build, Installation und Debugging.

Desktop-App

Die Desktop-App ist eine Electron-App. Mit Node.js 24 oder höher:

npm install --allow-git=all
npm run build          # development build, into dist/
npm start              # run it
npm run package:linux  # packages into release/ (also package:windows, package:mac)

Buildzeit-Einstellungen, wie z. B. vorzu konfigurierende Server, befinden sich in src/common/config/buildConfig.ts. Ohne Apple-Zertifikat können Sie AM_MAC_ADHOC_SIGN=true setzen, um die macOS-App ad hoc zu signieren, ohne Notarisierung: Macs mit Apple-Silizium lehnen nicht signierten Code ab. Der Workflow release.yml im Repository erstellt bei einem v*-Tag nicht signierte Pakete für Linux, Windows und macOS.

Mobile App

Die Mobile App ist eine React-Native-App; ihre README-Datei listet die Befehle (npm run ios, npm run android). Um eine eigene Kopie zu erstellen, benötigen Sie außerdem eigene Signierungsschlüssel, ein Firebase-Projekt für Android-Benachrichtigungen, einen APNs-Schlüssel für iOS und einen Push-Proxy, der diese Zugangsdaten verwaltet. Der Workflow release.yml im Repository erstellt bei einem v*-Tag das Android-APK und AAB sowie eine nicht signierte iOS-.ipa, ohne Store-Konten; die README-Datei listet die Secrets auf, die die Android-Builds signieren und Firebase einrichten.