GitRiver GitRiver
EN
Навигация

Решение проблем

Типичные ошибки при работе с GitRiver и способы их устранения

Мастер настройки не появляется

Причина: мастер запускается только если database_url не указан в конфиге и не задан через переменные окружения.

Решение: если вы задали GITRIVER_DB_* переменные в docker-compose - мастер не нужен, подключение к БД настроено автоматически. Если хотите мастер - уберите переменные GITRIVER_DB_* из docker-compose и перезапустите.

Сервер не запускается: ошибка подключения к БД

Проявление: в логах connection refused или authentication failed.

Проверьте:

  1. PostgreSQL запущен и доступен: pg_isready -h localhost -U gitriver
  2. Данные подключения в конфиге или env-переменных совпадают с настройками PostgreSQL
  3. В Docker Compose: depends_on с condition: service_healthy - GitRiver ждёт пока БД будет готова
  4. Порт не занят другим процессом

JWT-ошибки после перезапуска

Проявление: все пользователи разлогинены, ошибки invalid token.

Причина: JWT-секрет хранится в файле .jwt_secret рядом с конфигом (/var/lib/gitriver/.jwt_secret в Docker). Если файл удалён - все ранее выданные токены становятся недействительными.

Решение: пользователям нужно войти заново. Чтобы предотвратить - не удаляйте volume /var/lib/gitriver при обновлении.

CI-задачи не запускаются

Проверьте:

  1. Docker socket доступен: в docker-compose должен быть volume -v /var/run/docker.sock:/var/run/docker.sock
  2. Пользователь gitriver в группе docker: в Docker-образе это делается автоматически через docker-entrypoint.sh
  3. Лимит параллельных задач: проверьте ci_max_concurrent_jobs (по умолчанию 4). Если все слоты заняты - новые задачи ждут в очереди.
  4. Таймаут: если задача зависает - проверьте ci_job_timeout_secs
  5. Docker-образ: убедитесь, что образ указан в job (image: node:22)

CI-задачи зависают на git clone

Причина: большой репозиторий или медленная сеть.

Решение: увеличьте таймаут клонирования:

GITRIVER_CI_GIT_CLONE_TIMEOUT_SECS=300

По умолчанию - 120 секунд.

Git push отклоняется

Возможные причины:

  1. Защита ветки: push напрямую запрещён, нужен пулл-реквест. Проверьте: Настройки -> Защита веток
  2. Размер файла: для больших файлов используйте Git LFS. В nginx проверьте client_max_body_size (рекомендуется 512m)
  3. Нет прав: пользователь с ролью Reporter не может push’ить. Проверьте роль в группе или коллабораторах репозитория
  4. Подписанные коммиты: если в правиле защиты включено «Требовать подписанные коммиты» - все коммиты должны быть подписаны GPG

Docker push/pull не работает (Container Registry)

Проверьте:

  1. Авторизация: docker login git.example.com -u логин -p токен - токен, не пароль
  2. Формат тега: git.example.com/owner/repo:tag (не docker.io/...)
  3. Порт: если nginx слушает на нестандартном порту - укажите его в теге
  4. SSL: docker по умолчанию требует HTTPS. Для HTTP добавьте хост в insecure-registries в daemon.json

Email-уведомления не отправляются

Проверьте:

  1. SMTP настроен: Администрирование -> SMTP -> кнопка «Тест» (отправит тестовое письмо)
  2. from в конфиге - валидный email
  3. Порт правильный: 587 (STARTTLS) или 465 (implicit TLS)
  4. Провайдер не блокирует отправку (проверьте логи SMTP)

LDAP: пользователь не может войти

Проверьте:

  1. Тест подключения: Администрирование -> LDAP -> «Тест подключения» - показывает количество найденных пользователей
  2. Фильтр: {login} в фильтре заменяется на введённый логин. Проверьте, что фильтр находит пользователя: ldapsearch -x -H ldap://host -b "ou=users,dc=example,dc=com" "(uid=username)"
  3. Bind DN: если требуется - DN и пароль сервисного аккаунта должны быть указаны
  4. TLS: для ldaps:// сертификат CA должен быть доверенным

Высокое потребление дискового пространства

Причины и решения:

  1. Container Registry: запустите сборку мусора - Администрирование -> Хранилище -> «Очистка». Настройте политики хранения - автоудаление старых тегов
  2. CI-артефакты: проверьте ci_pipeline_retention_days (по умолчанию 90 дней). Уменьшите если нужно
  3. Git LFS: большие файлы хранятся в git_repos_path. Для production используйте S3-хранилище
  4. Бэкапы: проверьте ротацию - Администрирование -> Бэкапы -> Расписание -> максимальное количество копий

Логи

Docker

docker compose logs gitriver
docker compose logs gitriver --tail 100 -f

Локальная установка

Логи выводятся в stdout. Уровень логирования задаётся переменной RUST_LOG:

RUST_LOG=info gitriver run --config gitriver.toml
RUST_LOG=debug gitriver run --config gitriver.toml

Health check

curl http://localhost:3000/health

Ответ {"status":"ok","database":"connected"} - сервер работает нормально.