onboarding/README.md

# Онбординг: мы переехали с GitLab на Forgejo

GitLab выключен. Весь код, CI и деплой теперь на **Forgejo**:
**https://git.154.83.149.72.nip.io**

Твой аккаунт и все репы (код + история) уже перенесены — заводить ничего не надо.
Ниже — что поменялось лично для тебя и что сделать один раз.

---

## TL;DR (5 минут)
1. Зайди на https://git.154.83.149.72.nip.io — логин тот же, **временный пароль возьми у админа** → смени при первом входе.
2. Добавь свой SSH-ключ (Settings → SSH/GPG Keys). Новый порт — **2223**.
3. Перепривяжи `remote` своих реп на новый хост.
4. Деплой теперь через `.forgejo/workflows/deploy.yml` + `.env` (форкни `templates/starter`). Push в `main` → сайт с SSL.

---

## 1. Доступ
- Форж: **https://git.154.83.149.72.nip.io**
- Логин: **твой прежний username** (как на GitLab).
- Пароль: **временный, возьми у админа**. При первом входе форж заставит сменить.

> ⚠️ Пока не сменишь пароль в вебе — git по HTTPS/паролю работать НЕ будет (так задумано: временный пароль одноразовый).

## 2. Git: новый хост, порт и ключ
SSH-ключи с GitLab **не переехали** — добавь заново.

| | было (GitLab) | стало (Forgejo) |
|---|---|---|
| SSH | `git@gitlab.extractl.online:2222` | `git@git.154.83.149.72.nip.io:2223` |
| HTTPS | `https://gitlab.extractl.online/…` | `https://git.154.83.149.72.nip.io/…` |

1. **Settings → SSH/GPG Keys → Add Key** → вставь `~/.ssh/id_ed25519.pub`.
2. `~/.ssh/config`:
   ```
   Host git.154.83.149.72.nip.io
     Port 2223
     User git
   ```
3. Перепривяжи каждую репу:
   ```
   git remote set-url origin git@git.154.83.149.72.nip.io:<твой-логин>/<репа>.git
   ```
   (Или HTTPS — логин + новый пароль, без `~/.ssh/config`.)

## 3. Твои репы
Уже на Forgejo, код и история целы. Просто перепривяжи `remote` (см. выше) — и работаешь как раньше.

## 4. Деплой: новый флоу
Принцип тот же (`.env` с `DOMAIN` → push → сайт с SSL), формат CI поменялся.

| | было (GitLab) | стало (Forgejo) |
|---|---|---|
| CI-файл | `.gitlab-ci.yml` (`include auto.yml`) | `.forgejo/workflows/deploy.yml` |
| конфиг | `.env` | `.env` (почти то же) |
| триггер | push в `main` | push в дефолт-ветку |
| скорость | ~1–2 мин | ~20–60 сек |

**Что сделать:** добавь в свою (уже существующую) репу 2 файла — возьми их из
**`templates/starter`** (https://git.154.83.149.72.nip.io/templates/starter).
**Форкать стартер не надо** — он просто источник этих двух файлов:
- `.forgejo/workflows/deploy.yml` — трогать не надо (тянет платформенный action по ссылке)
- `.env` — минимум `DOMAIN=твойсайт.com`

Push в `main` → сайт встаёт. (Форк/клон всего стартера не нужен даже для проекта с нуля — достаточно этих 2 файлов в твоём репозитории.)

### Тип проекта — новое поле `DEPLOY` в `.env` (можно не указывать, авто-детект)
- **`static`** — фронт (Vite / CRA / Next static export): build → раздаётся статикой. Дефолт, если в корне НЕТ `Dockerfile`. Самый быстрый.
- **`docker`** — свой `Dockerfile` → контейнер. Дефолт, если `Dockerfile` есть.
- **`docker-db`** — docker + персистентная **SQLite**: монтируется volume в `/data`, прокидывается `DATABASE_URL=file:/data/app.db`.

## 5. Секреты (DATABASE_URL, API-ключи) — поменялось
| | было (GitLab) | стало (Forgejo) |
|---|---|---|
| где задать | CI/CD Variables с префиксом `RUNTIME_` | **Settings → Actions → Secrets** (имя секрета = имя переменной) |
| как включить | автоматом все `RUNTIME_*` | перечислить в `.env`: `RUNTIME_KEYS=DATABASE_URL,JWT_SECRET` |

В коде читаешь как раньше — `process.env.DATABASE_URL`. Для `DEPLOY=docker-db` переменную `DATABASE_URL` указывать не надо (ставится автоматически).

## 6. Ещё мелочи
- **Build на bun** — если закоммитишь `bun.lock`, install в 10–30× быстрее npm. Для Web3/Solana-проектов огромная разница.
- **Registry больше не нужен** — образ собирается и запускается на месте.
- **Kill-switch** как раньше: `ENABLED=false` в `.env` → сайт отдаёт 404; убери строку (или `true`) → вернётся.
- **БД**: вместо общего Postgres — своя SQLite в volume (`docker-db`). Если нужна была твоя старая Postgres-дата — скажи админу, достанем из бэкапа.

## 7. `curl get.твойдомен | sh` — установочный сабдомен (self-service)

Хочешь красивый one-liner установки (`curl get.mysite.com | sh`)? Делается **сам,
без админа**, для `static`-сайтов. Три шага:

1. **Скрипт кладёшь в репу** → `public/install.sh` (папка `public/` у Vite попадает
   в `dist/` как есть, т.е. окажется в корне сайта).
2. **DNS**: в своём регистраторе добавь A-запись `get` → IP сервера платформы
   (там же, где `@` и `www`). Только `get`, host = `get`.
3. **`.env`**: добавь строку `INSTALL_SH=install.sh` и `git push`.

Всё. CI сам поднимет `get.твойдомен`, выпустит SSL и будет отдавать `install.sh`
как `text/plain` (то, что нужно для `| sh`). Убери `INSTALL_SH` из `.env` и запушь —
сабдомен снимется.

> Тонкости: работает для `static`; имя файла в `INSTALL_SH` — как в сборке (лежит в
> корне `dist/`). Если сабдомен отдаёт 404 — значит скрипта ещё нет в сборке или
> DNS-запись `get` не указывает на наш IP (в логе деплоя будет `::warning::` про это).
> Апекс-домен и `www` не затрагиваются — это отдельный фрагмент.

## 8. Полная дока
Деплой во всех деталях (CRA, Next.js, монорепо, кастомный Dockerfile, авто-www и т.д.) —
**README в `templates/starter`**: https://git.154.83.149.72.nip.io/templates/starter

Застрял — пиши админу.