Схема: Gitea Actions + раннер (образ gitea/runner — старый gitea/act_runner уже deprecated) внутри k3s. Пайплайн запускается вручную из вкладки Actions репозитория (кнопка "Run workflow"), с выбором target: back / front / all — аналог кнопки "Run pipeline" с переменной в GitLab.

Это первая рабочая версия. Она не протестирована на реальном кластере (я не имею доступа к твоему серверу) — почти наверняка на первом запуске придётся что-то поправить по логам, это нормально.

Что нужно сделать один раз руками

1. Включить Actions в Gitea

Site Administration → Configuration → убедиться, что Actions включены ([actions] ENABLED = true в app.ini, если ещё не включено — потребуется перезапуск Gitea). Затем в самом репозитории: Settings → Actions → включить.

2. Развернуть раннера в кластере

# впиши токен регистрации (Site Administration → Actions → Runners →
# Create new Runner, или в настройках репозитория/организации)
echo -n "<токен>" | base64
# вставь результат вместо PLACEHOLDER_BASE64_TOKEN в runner-deployment.yaml,
# поправь GITEA_INSTANCE_URL на свой адрес

kubectl apply -f deployment/ci/namespace.yaml
kubectl apply -f deployment/ci/runner-rbac.yaml
kubectl apply -f deployment/ci/runner-deployment.yaml

Раннер должен появиться в Gitea (Site Administration → Actions → Runners) со статусом Idle. Если нет — смотри kubectl logs -n ci deploy/act-runner (там же будет видно, если, например, неверный GITEA_INSTANCE_URL или токен).

3. Собрать kubeconfig для пайплайна

После применения runner-rbac.yaml у нас есть токен ServiceAccount architector-ci (лежит в namespace ci, но права у него через ClusterRole — на весь кластер, не только на media, чтобы этим же раннером и токеном можно было деплоить будущие проекты в других namespace'ах). Собираем из него kubeconfig (с любой машины, у которой уже есть доступ к кластеру через свой kubectl):

TOKEN=$(kubectl get secret architector-ci-token -n ci -o jsonpath='{.data.token}' | base64 -d)
CA=$(kubectl get secret architector-ci-token -n ci -o jsonpath='{.data.ca\.crt}')
SERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')

cat > architector-ci-kubeconfig.yaml <<EOF
apiVersion: v1
kind: Config
clusters:
  - name: k3s
    cluster:
      server: ${SERVER}
      certificate-authority-data: ${CA}
contexts:
  - name: architector-ci
    context:
      cluster: k3s
      namespace: media
      user: architector-ci
current-context: architector-ci
users:
  - name: architector-ci
    user:
      token: ${TOKEN}
EOF

base64 -w0 architector-ci-kubeconfig.yaml   # это значение пойдёт в секрет KUBE_CONFIG

4. Секреты пайплайна в Gitea

Repository → Settings → Actions → Secrets, добавить:

DOCKERHUB_USER, DOCKERHUB_TOKEN — логин и access token Docker Hub (Docker Hub → Account Settings → Security → New Access Token, не пароль).
KUBE_CONFIG — вывод команды base64 -w0 из шага 3.

5. Проверка

Repository → Actions → Deploy → Run workflow → выбрать target → Run. Смотреть логи джобов там же.

На будущее

Ты упоминал переезд фронта на PVC вместо hostPath — когда дойдём до этого, build-front job поменяется на полноценную сборку Docker-образа (нужен будет свой deployment/charts/front/Dockerfile) плюс helm upgrade для front-чарта, аналогично backend. hostPath-подход в runner-deployment.yaml тогда тоже уйдёт — обсудим отдельно, как ты и предлагал.

README.md Unescape Escape

CI/CD: пуш → ручной деплой одной кнопкой