Budowanie ze źródła

Ta strona wyjaśnia, jak zbudować i uruchomić Antimatter z kodu źródłowego, aby nad nim pracować lub tworzyć własne buildy. Omawia serwer i interfejsy webowe, które znajdują się w jednym repozytorium, a następnie obraz Docker i aplikacje.

Wymagania

  • Przejdź do wersji w server/go.mod (1.26.7 na moment pisania).
  • Node.js i npm w wersjach określonych w .nvmrc i webapp/package.json (Node 24.11.1 z npm 11.6.2). Dzięki mise plik mise.toml w repozytorium instaluje odpowiednią wersję Node.
  • Docker z Compose: środowisko deweloperskie uruchamia PostgreSQL i kilka innych usług w kontenerach.
  • make, git oraz komputer z systemem Linux lub macOS.
  • Pamięć RAM: budowanie interfejsów webowych to najcięższa część procesu. Zaplanuj 16 GB RAM; zobacz Budowanie i pamięć.
git clone https://github.com/AntimatterChat/antimatter.git
cd antimatter

Repozytorium zawiera serwer w server/, interfejsy webowe w webapp/ (Fusion w webapp/fusion, klasyczny w webapp/channels, wspólne pakiety w webapp/platform) oraz testy end-to-end w e2e-tests/.

Uruchomienie serwera deweloperskiego

cd server
make run

make run uruchamia kontenery deweloperskie (PostgreSQL, Redis, przechwytywacz poczty i narzędzia monitoringu), podłącza buildy aplikacji webowej, uruchamia serwer w tle za pomocą go run oraz startuje watcher aplikacji webowej, który ponownie buduje klasyczny interfejs podczas edycji. Otwórz http://localhost:8065 i utwórz konto: pierwsze staje się administratorem systemu.

Polecenie (w server/)Opis
make run-server, make run-clientUruchom tylko serwer lub tylko watcher aplikacji webowej.
make restart-serverUruchom ponownie serwer po zmianie kodu Go.
make stopZatrzymaj serwer, watcher i kontenery.
make debug-serverUruchom serwer w debuggerze Delve.
make run-cli ARGS="-version"Uruchom polecenie serwera.
make config-resetZresetuj config/config.json do wartości domyślnych.
make clean, make nukeUsuń pliki buildu; nuke usuwa również dane deweloperskie.

Baza danych deweloperska to postgres://mmuser:mostest_password@localhost/mattermost_test, domyślne źródło danych serwera. Wybierz, które kontenery mają się uruchomić, za pomocą ENABLED_DOCKER_SERVICES w pliku server/config.override.mk lub w swoim środowisku (zobacz server/config.mk).

Interfejsy webowe

W webapp/:

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

Zbudowane pliki trafiają do webapp/channels/dist (klasyczny) i webapp/fusion/dist (Fusion). Wykonanie make client w katalogu server/ tworzy linki server/client i server/client-fusion, z których serwer serwuje interfejsy: klasyczny pod /static/, a Fusion pod /static/fusion/.

  • npm run run (lub make run w webapp/) monitoruje zmiany i ponownie buduje klasyczny interfejs. Aby ponownie budować również Fusion, dodaj WATCH_FUSION=true.
  • npm run dev-server (make dev) uruchamia serwer deweloperski webpacka: klasyczny na porcie 9005, Fusion na porcie 9006.
  • Aby wyświetlić w przeglądarce jeden z interfejsów, dodaj do adresu dowolnej strony parametr ?webui=fusion lub ?webui=classic.

Testy i kontrole

PolecenieGdzieOpis
make test-serverserver/Zestaw testów serwera, uruchamiany w kontenerach deweloperskich. Zajmuje dużo czasu.
make test-server-quickserver/Tylko krótkie testy.
go test ./channels/app/... -run TestNameserver/Jeden pakiet lub test, przy uruchomionych kontenerach (make start-docker).
make check-styleserver/go vet, golangci-lint i inne kontrole Go.
make testwebapp/Testy jednostkowe aplikacji webowej (Jest) dla każdego pakietu.
npm run test -- <pattern>webapp/fusionWybrane testy Fusion.
make check-style, make check-typeswebapp/ESLint i TypeScript.
make i18n-extractserver/ i webapp/Aktualizuje angielskie pliki z napisami po dodaniu lub zmianie tekstów (patrz Tłumaczenia).

W katalogu server/ używaj make modules-tidy zamiast go mod tidy.

Archiwa wydawnicze

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 buduje interfejsy webowe i binaria dla Linuksa w jednym kroku. Archiwum zawiera bin/antimatter, bin/amctl, domyślny config/config.json z README.md opisującym zmianę ustawień, oba interfejsy webowe, szablony, czcionki i tłumaczenia. Inne platformy: make package-osx, make package-windows, make package-freebsd.

Aplikacje wbudowane

Zwykłe make package-linux tworzy archiwum bez aplikacji. Aby je dołączyć, tak jak w oficjalnych wydaniach, najpierw pobierz podpisane pakiety aplikacji i wskaż ich folder:

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 pobiera najnowsze wydanie GitHub dla każdej aplikacji wymienionej w plugins.json w repozytorium antimatter-docker, wraz z podpisem, i weryfikuje podpis względem klucza pluginów Antimatter. Domyślnie pobiera Whiteboard, kanały głosowe, rozmowy, agentów, listy do zrobienia, ankiety, notatki, GIF-y i memy; zmienna AM_BUNDLED_APPS (nazwy repozytoriów, oddzielone spacjami) zmienia tę listę. Aplikacje bez wydania lub bez podpisu są pomijane z ostrzeżeniem. Pakiety trafiają do folderu prepackaged_plugins/ w archiwum.

Pakiety .deb i .rpm

build/package/build-packages.sh <archive> <amd64|arm64> <version> <out-dir> tworzy z archiwum wydania pakiety .deb i .rpm typu all-in-one, z użyciem nfpm. Przewodnik administratora opisuje, co instalują: zobacz Instalacja pakietu .deb lub .rpm.

Przepływ wydawniczy

Przepływ antimatter-release.yml w repozytorium serwera wykonuje na GitHubie wszystkie te kroki: przy tagu v* buduje archiwa i pakiety dla amd64 i arm64, z plikiem SHA256SUMS, i publikuje je jako wydanie GitHub dla danego tagu (wydanie wstępne dla wersji z -). Uruchomiony ręcznie, numeruje build jako 0.9.0-dev.<run> i zachowuje pliki jako artefakty przepływu. Każde repozytorium aplikacji ma przepływ release.yml, który publikuje podpisany pakiet w ten sam sposób.

Obraz Docker

Repozytorium antimatter-docker buduje publikowane obrazy, zawierające serwer wraz z aplikacjami, całkowicie wewnątrz Dockera:

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

Wymagany jest Docker z buildx, Python 3, git i gpg, około 16 GB RAM i 30 GB miejsca na dysku. Wynik jest ładowany jako ghcr.io/antimatterchat/antimatter:dev; przetestuj go za pomocą ANTIMATTER_IMAGE=ghcr.io/antimatterchat/antimatter:dev docker compose -f compose.local.yml up -d. Plik plugins.json zawiera listę aplikacji i ich wersji, a README repozytorium opisuje dostępne warianty.

Skrypt build-all.sh podpisuje dołączone aplikacje kluczem podpisowym Antimatter, a budowanie obrazu odrzuca aplikacje bez podpisu. Jeśli nie masz dostępu do tego klucza prywatnego, który posiadają wyłącznie opiekunowie projektu, wykonaj tylko pierwsze kroki: scripts/fetch-sources.sh, scripts/build-plugins.sh (pakiety aplikacji w out/plugins/) oraz scripts/build-server.sh (archiwa serwera w out/server/).

Budowanie i pamięć

Interfejsy webowe to duże budowania webpack, a najczęstszą przyczyną niepowodzenia budowania jest wyczerpanie pamięci.

  • Polecenie npm run build buduje klasyczny interfejs, a następnie Fusion, jeden po drugim, a nie jednocześnie, aby utrzymać szczytowe zużycie na niższym poziomie. Nie uruchamiaj ich równolegle samodzielnie.
  • Minifikator uruchamia jeden procesor roboczy na każdy rdzeń procesora. Na maszynie z dużą liczbą rdzeni i małą ilością pamięci ogranicz liczbę procesorów widocznych dla budowania: taskset -c 0-5 npm run build.
  • Jeśli Node wyczerpie pamięć stosu (heap), podnieś jej limit: NODE_OPTIONS=--max-old-space-size=6144. Budowanie w Dockerze używa tej wartości (BUILD_NODE_OPTIONS w build.env).
  • Unikaj jednoczesnego uruchamiania pełnego zestawu testów serwera, budowania interfejsu webowego i budowania obrazu Docker na małej maszynie.

Aplikacje

Każda aplikacja (wtyczka) ma własne repozytorium i plik Makefile; polecenie make dist buduje jej pakiet. Zobacz Budowanie, instalacja i debugowanie.

Aplikacja desktopowa

Aplikacja desktopowa to aplikacja Electron. Wymaga Node.js 24 lub nowszej wersji:

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)

Ustawienia czasu kompilacji, takie jak serwery do wstępnej konfiguracji, znajdują się w src/common/config/buildConfig.ts. Jeśli nie masz certyfikatu Apple, ustaw AM_MAC_ADHOC_SIGN=true, aby podpisać aplikację macOS ad hoc, bez notaryzacji: komputery Mac z procesorami Apple Silicon odrzucają kod bez podpisu. Workflow release.yml w repozytorium buduje niepodpisane pakiety dla systemów Linux, Windows i macOS przy oznaczeniu v*.

Aplikacja mobilna

Aplikacja mobilna to aplikacja React Native; jej plik README zawiera listę poleceń (npm run ios, npm run android). Aby zbudować własną kopię, potrzebujesz również własnych kluczy podpisu, projektu Firebase dla powiadomień na Androidzie, klucza APNs dla iOS oraz proxy push przechowującego te dane uwierzytelniające. Workflow release.yml w repozytorium buduje APK i AAB dla Androida oraz niepodpisane .ipa dla iOS przy oznaczeniu v*, bez kont w sklepach; jego plik README zawiera listę sekretów służących do podpisywania buildu Androida i konfiguracji Firebase.