Создание Gitea-репо (private)

⚙️ СЛУЖЕБНЫЙ РАНБУК — только для администратора проекта .admin. Применять/выполнять шаги может только .admin (оператор проекта admin). Другим проектам/агентам — читать по запросу, не выполнять. Из проекта не выносить: не копировать в другие вики, не пересказывать, не публиковать. Нужен деплой или прод-операция по этому ранбуку — поставить задачу админу (.admin) и написать письмо. Админ выполняет, остальные верифицируют.

Scope

Создание private Gitea-репо для нового проекта. Вход: ops-задача на борде .admin (task_create, priority P0) + покрывающее письмо от заказчика (таска не пингует живую сессию). Парная review НЕ нужна (ops-задача).

Механика: репо создаёт admin (OpeItcLoc03) через POST /user/repos → transfer к целевому владельцу. Это канон (скил project-create): admin-endpoint отказывает без write:admin.

Артефакты

Gitea: https://git.kzntsv.site, API base /api/v1.
Admin-токен: <из pass gitea/admin-token> (login OpeItcLoc03, id 1, is_admin).
Push-токен: user-токен целевого владельца с repo:write (для victor — <из pass gitea/victor-books-ci-bookva-overlay>).
SSH-порт git.kzntsv.site — 2222 (не 22).

Шаги

Получить имя и владельца от оператора. Никогда не выводить сам (hard rule скила project-create; прецедент tg-digest — решили по аналогии, оператор поправил).
Pre-flight (с admin-токеном):
- GET /users/<owner> → 200 = владелец существует;
- GET /repos/<owner>/<name> → 404 = имя свободно.
Без auth приватные/скрытые сущности могут давать 404 даже если существуют — проверять с токеном.

Создать (от admin, owner = OpeItcLoc03):

TOK=$(pass show gitea/admin-token)
curl -s -X POST "$BASE/user/repos" \
  -H "Authorization: token $TOK" -H "Content-Type: application/json" \
  -d '{"name":"<name>","private":true,"description":"<desc>","auto_init":false}'

auto_init:false — без seed-коммита (репо пустое, готово к bootstrap).

Transfer к владельцу:

curl -s -X POST "$BASE/repos/OpeItcLoc03/<name>/transfer" \
  -H "Authorization: token $TOK" -H "Content-Type: application/json" \
  -d '{"new_owner":"<owner>","team_ids":[]}'

Verify: в ответе transfer — full_name = <owner>/<name>, private:true, empty:true, default_branch (ожид. main).
Проверить push-токен: GET /repos/<owner>/<name> с user-токеном → permissions.push == true.
Ответить письмом (inbox_send, from .admin, type action) заказчику: clone URLs (HTTPS + SSH), push-токен как pass-реф (только имя записи, не значение), подтверждение что репо пустое. Закрыть ops-таску (task_close, reason + verify).

Verify / smoke

Репо указано как private и пустое (в списке репо владельца).
User-токен владельца видит репо и имеет push-права.
Ответ-письмо ушло (clone URLs + токен-реф + подтверждение).

Rollback

Сразу после создания (до transfer): DELETE /repos/OpeItcLoc03/<name>.
После transfer: DELETE /repos/<owner>/<name> (с admin-токеном).

Gotchas

Gitea-эндпоинты без auth могут 404 на существующие (скрытые/приватные) сущности — все проверки с токеном. (2026-08-27)
Имя/владелец — решение оператора, не по аналогии из соседних проектов (hard rule, tg-digest кейс). (2026-08-27)
SSH-порт Gitea — 2222, не 22. (2026-08-27)
POST /user/repos создаёт на владельца токена (OpeItcLoc03), потом transfer — нужно admin-право (иначе 403). (2026-08-27)
Секреты: в ранбуке/письме только pass-рефы; значения токенов не сыпать (write-time secret-scan блокирует 422). (2026-08-27)
/users/<u>? без auth → 404 даже для существующего (victor) — проверять с admin-токеном. (2026-08-27)

5.4 KiB Raw Blame History Unescape Escape