Wire JWT_SECRET/POSTGRES_PASSWORD through Gitea Actions secrets

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.

.gitea/workflows/ci-cd.yml

@@ -10,13 +10,33 @@ on:
 # checkout path — otherwise `docker compose` would derive the project name
 # from the checkout directory, potentially spinning up a second stack and
 # losing the `pgdata` volume instead of updating the running one.
+#
+# JWT_SECRET/POSTGRES_PASSWORD come from Gitea's own Actions secrets store
+# rather than the `.env` file DEPLOY.md has the human create in
+# `/opt/ruvdstests` — the job checks out into the runner's own workspace, not
+# that directory, so there's no `.env` for `docker compose` to read here.
+# Must match the values already in that `.env` file: on `Deploy` this
+# `docker compose up -d` targets the same running project (via
+# COMPOSE_PROJECT_NAME above), and a different POSTGRES_PASSWORD than what
+# the live `pgdata` volume was initialized with breaks the DB connection.
 env:
   COMPOSE_PROJECT_NAME: ruvdstests
+  JWT_SECRET: ${{ secrets.JWT_SECRET }}
+  POSTGRES_PASSWORD: ${{ secrets.POSTGRES_PASSWORD }}
 
 jobs:
   build-test-deploy:
     runs-on: host
     steps:
+      # `runs-on: host` runs every step directly on the bare runner
+      # container instead of spinning up a fresh container per job, and
+      # `actions/checkout` below is a JS action — it needs a `node` binary
+      # on PATH to run at all, which this image doesn't ship. Has to come
+      # before Checkout, since Checkout itself is what fails without it.
+      - name: Install Node.js
+        shell: bash
+        run: apk add --no-cache nodejs
+
       - name: Checkout
         uses: https://github.com/actions/checkout@v4
 

docs/CI-CD.md

@@ -37,13 +37,25 @@ docker run -d --name gitea-ci-runner --restart unless-stopped \
 
 `host:host` — раннер выполняет джобы напрямую в своём собственном контейнере (никаких вложенных
 контейнеров на каждый джоб), у него смонтирован docker.sock хоста — поэтому `docker compose`
-внутри джоба управляет реальными контейнерами на этой машине. Джоб сам ставит себе `docker-cli` и
-.NET SDK через `apk`/`dotnet-install.sh` (см. workflow) — образ раннера намеренно голый, чтобы не
-поддерживать отдельный кастомный образ.
+внутри джоба управляет реальными контейнерами на этой машине. Джоб сам ставит себе `node`,
+`docker-cli` и .NET SDK через `apk`/`dotnet-install.sh` (см. workflow) — образ раннера намеренно
+голый, чтобы не поддерживать отдельный кастомный образ. `node` ставится первым шагом, до
+`actions/checkout` — этот шаг сам является JS-экшеном и без `node` в PATH падает с `Cannot find:
+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** репозитория должен появиться