Wire JWT_SECRET/POSTGRES_PASSWORD through Gitea Actions secrets
All checks were successful
CI/CD / build-test-deploy (pull_request) Successful in 4m43s

The job checks out into the runner's own workspace, not
/opt/ruvdstests where DEPLOY.md has the human create a .env file — so
docker compose here had no .env to read JWT_SECRET from and failed
outright. POSTGRES_PASSWORD would have silently fallen back to the
compose file's devpassword default instead of erroring, which on
Deploy would have broken auth against the already-initialized pgdata
volume.
This commit is contained in:
danamir
2026-08-09 01:04:13 +03:00
parent 0a1407719e
commit 8c46ef1972
2 changed files with 21 additions and 0 deletions

View File

@@ -46,6 +46,16 @@ node in PATH` раньше, чем успевает выполниться чт
Проверить, что раннер подключился: Site Administration → Actions → Runners — должен появиться
`ruvdstest-prod` со статусом Idle/Online.
## Секреты
Джоб чекаутит репозиторий во временную директорию раннера, а не в `/opt/ruvdstests` — своего
`.env` там нет, поэтому `JWT_SECRET`/`POSTGRES_PASSWORD` для `docker compose build`/`up` берутся не
из файла, а из хранилища секретов самой Gitea Actions: Settings репозитория → Actions → Secrets →
**Add Secret**. Завести `JWT_SECRET` и `POSTGRES_PASSWORD` со **значениями, совпадающими с тем, что
уже лежит в `/opt/ruvdstests/.env`** на сервере (`cat /opt/ruvdstests/.env` на сервере, скопировать
оттуда) — деплой-шаг пересоздаёт тот же самый запущенный проект (`COMPOSE_PROJECT_NAME` выше), и
рассинхронизация паролей с уже инициализированным `pgdata`-volume сломает подключение к БД.
## Проверка
Сделайте любой коммит и запушьте в `master` — во вкладке **Actions** репозитория должен появиться