Workflow CI гоняет gofmt, vet, тесты и сборку на каждый push в main; workflow Release по тегу v* собирает бинарники под linux/amd64 и arm64, считает контрольные суммы и публикует релиз через API Gitea. Оба workflow забирают код через git, а не actions/checkout: это JS-действие, которому нужен Node внутри контейнера, а в образе golang его нет. Заодно сборка перестала зависеть от доступности github.com, что для self-hosted инстанса существенно. Скрипт deploy/get.sh ставит последний релиз одной командой: определяет архитектуру, забирает файлы релиза, сверяет sha256 (бинарник ставится с правами root) и передаёт управление install.sh. Обновление — та же команда. Версия сборки попадает в бинарник через ldflags, доступна как `pzmanager version` и видна в панели на вкладке «Настройки»: без неё нельзя понять, какой релиз стоит на сервере. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -47,21 +47,30 @@ systemd ──> pzmanager ──> start-server.sh ──> java (GameServer)
|
||||
|
||||
## Быстрый старт
|
||||
|
||||
Собрать бинарник (нужен Go 1.24+; собирать можно на любой ОС, включая Windows):
|
||||
На чистом Ubuntu/Debian всё ставится одной командой — она возьмёт последний
|
||||
релиз, проверит контрольные суммы и настроит systemd:
|
||||
|
||||
```bash
|
||||
make build-linux
|
||||
curl -fsSL https://gitea.hsrv.site/mrleo1nid/pzmanager/raw/branch/main/deploy/get.sh | sudo bash
|
||||
```
|
||||
|
||||
Скопировать `pzmanager` и папку `deploy/` на сервер и запустить установщик:
|
||||
По умолчанию панель слушает `127.0.0.1:8080` — только с самой машины. Чтобы
|
||||
она была доступна в локальной сети, укажите адрес сервера:
|
||||
|
||||
```bash
|
||||
sudo ./deploy/install.sh
|
||||
curl -fsSL https://gitea.hsrv.site/mrleo1nid/pzmanager/raw/branch/main/deploy/get.sh \
|
||||
| sudo PZ_LISTEN=10.10.1.142:8080 bash
|
||||
```
|
||||
|
||||
Установщик заведёт системного пользователя `pzserver`, поставит зависимости
|
||||
(SteamCMD, JRE, SDL2), положит бинарник в `/usr/local/bin`, создаст структуру
|
||||
в `/opt/pzmanager` и включит systemd-юнит:
|
||||
Переменные: `PZ_LISTEN` (адрес панели), `PZ_HOME` (каталог, по умолчанию
|
||||
`/opt/pzmanager`), `PZ_USER` (системный пользователь), `PZ_VERSION`
|
||||
(конкретный тег вместо последнего).
|
||||
|
||||
Скрипт запускается от root, так что перед первым запуском его разумно
|
||||
прочитать: [deploy/get.sh](deploy/get.sh).
|
||||
|
||||
Установщик поставит зависимости (SteamCMD, JRE, SDL2), заведёт пользователя
|
||||
`pzserver` без shell, положит бинарник в `/usr/local/bin` и создаст структуру:
|
||||
|
||||
```
|
||||
/opt/pzmanager/
|
||||
@@ -72,17 +81,8 @@ sudo ./deploy/install.sh
|
||||
└── backups/ архивы
|
||||
```
|
||||
|
||||
Куда ставить и на каком адресе слушать, задаётся переменными окружения:
|
||||
|
||||
```bash
|
||||
# панель доступна в локальной сети по адресу машины
|
||||
sudo PZ_LISTEN=10.10.1.142:8080 ./deploy/install.sh
|
||||
|
||||
# другой каталог и пользователь
|
||||
sudo PZ_HOME=/srv/pz PZ_USER=zomboid ./deploy/install.sh
|
||||
```
|
||||
|
||||
По умолчанию панель слушает `127.0.0.1:8080` — только с самой машины.
|
||||
**Обновление** — та же команда: конфиг, миры и учётные записи не трогаются,
|
||||
меняется только бинарник.
|
||||
|
||||
Дальше:
|
||||
|
||||
@@ -113,8 +113,20 @@ sudo ufw allow 16261/udp # игровой порт
|
||||
sudo ufw allow 16262/udp # второй игровой порт
|
||||
```
|
||||
|
||||
Обновление ставится поверх: соберите новый бинарник и повторите
|
||||
`sudo ./deploy/install.sh` — конфиг, миры и учётки останутся на месте.
|
||||
### Установка из исходников
|
||||
|
||||
Если релизам предпочитаете свою сборку (нужен Go 1.24+, собирать можно на
|
||||
любой ОС, включая Windows):
|
||||
|
||||
```bash
|
||||
make build-linux
|
||||
```
|
||||
|
||||
Скопируйте `pzmanager` и папку `deploy/` на сервер и запустите установщик:
|
||||
|
||||
```bash
|
||||
sudo PZ_LISTEN=10.10.1.142:8080 ./deploy/install.sh
|
||||
```
|
||||
|
||||
## Моды
|
||||
|
||||
@@ -290,6 +302,33 @@ backup:
|
||||
Тем не менее доступ к панели равносилен доступу к игровому серверу, так что
|
||||
пароль стоит выбрать не короче того, что вы поставили бы на SSH.
|
||||
|
||||
## Сборка и релизы
|
||||
|
||||
Репозиторий собирается Gitea Actions ([`.gitea/workflows`](.gitea/workflows)):
|
||||
|
||||
- **CI** — на каждый push и pull request в `main`: `gofmt`, `go vet`, тесты,
|
||||
проверка сборки под Linux и синтаксиса скриптов установки.
|
||||
- **Release** — на тег `v*`: собирает бинарники под `linux/amd64` и
|
||||
`linux/arm64`, считает контрольные суммы и публикует релиз с ними и
|
||||
скриптами установки.
|
||||
|
||||
Выпуск новой версии:
|
||||
|
||||
```bash
|
||||
git tag -a v1.2.3 -m "Описание релиза" && git push origin v1.2.3
|
||||
```
|
||||
|
||||
Версия попадает в бинарник через `-ldflags -X main.version=` и видна в
|
||||
`pzmanager version` и в панели на вкладке «Настройки».
|
||||
|
||||
Workflow не зависят от github.com и от Node внутри контейнера: код забирается
|
||||
через `git`, а релиз публикуется прямо в API Gitea. Токен Actions выдаёт сам;
|
||||
если в настройках инстанса его права урезаны, заведите секрет `RELEASE_TOKEN`
|
||||
с доступом на запись в репозиторий.
|
||||
|
||||
Для работы Actions нужен зарегистрированный runner с меткой `ubuntu-latest`,
|
||||
умеющий запускать контейнеры (`docker`).
|
||||
|
||||
## Разработка
|
||||
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user