Перейти к содержимому
GitRiverGitRiver
EN
Навигация

Обновление с 1.0.0 на 1.1.0

Что проверить в базе перед обновлением, что меняется у владельца платной лицензии и у клиентов API, какая настройка перестала действовать

Отдельного порядка обновления нет: обновляется образ, пакет или чарт, а миграции схемы сервер применяет сам при старте. В 1.1.0 их 187, из них 98 появились после 1.0.0.

Но четыре миграции намеренно останавливают обновление, если в базе лежат данные, которые нельзя слить за владельца, и семь вещей меняются в поведении. Всё это названо ниже поимённо.

Перед обновлением: четыре случая, на которых обновление остановится

Сервер не стартует, данные не трогает и называет причину. Разберите её и повторите обновление.

Что нашлось в базе Что делать
Пакеты NuGet в одном репозитории, различающиеся только регистром имени Свести к одному имени - готовые запросы ниже
Версии NuGet, которые не нормализуются; дубли, возникающие после нормализации; два файла .nupkg у одной версии Оставить по одному файлу на версию, неоднозначные версии переименовать
Имя пользователя совпадает с путём группы Переименовать одно из двух: после обновления имена живут в одном пространстве
Активации лицензии ссылаются на разные идентификаторы установки Признак того, что база уже расщеплена (две установки на одной копии). Напишите в поддержку до обновления

Что меняется у владельца платной лицензии

Корпоративные возможности ушли из Pro в Max. Вход по SAML SSO и его настройки, управление учётными записями по SCIM, LDAP, журнал аудита, назначение квот, правила по адресу уровня установки, оформление под свою марку и пределы черновиков знания открывает теперь редакция Max. В 1.0.0 их открывала любая действующая лицензия Pro.

Установка на лицензии Pro, которая пользовалась хоть чем-то из этого списка, получит на этих вызовах 403 license_required. Переход: издатель выдаёт файл активации Max с тем же идентификатором лицензии, срок при этом двигать не обязательно; мест не удваивается, вторая строка в списке лицензий не появляется. Вводится он там же, где продление — продление и смена редакции.

Оплаченное не пропадает: лицензия Pro, выданная до 15 сентября 2026, до конца оплаченного срока исполняется как Max.

Места Pro заработали. Лицензия с ограничением по числу мест открывает платные разделы только тем участникам, у кого признак места проставлен — места. Установок с лицензией без ограничения мест это не касается.

Право подтверждается ограниченное время. Подписанный ответ активации годен теперь 14–90 дней по сроку подписки, а не до конца срока лицензии. Пока подписи доходят — отметкой к серверу лицензий или файлом, вставленным вручную, — не меняется ничего. Когда перестают, платные возможности закрываются раньше конца оплаченного срока, но оплаченное не сгорает — срок подтверждения.

Что меняется у клиентов API

Переход на 1.1.0 — единственное место, где меняется то, что дальше объявлено неизменным: обещание совместимости /api/v1 действует начиная с 1.1.0. Меняется четыре вещи.

Форма ответа стала страницей в трёх местах. Вместо массива верхнего уровня приходит {"items": [...], "next_cursor": ...}: комментарии задачи, комментарии и обзоры пулл-реквеста; пакеты репозитория и версии одного пакета; сводные списки квот GET /admin/quotas/users и /groups.

Неизвестное поле в теле запроса отвергается - 400 с кодом validation, текст называет нераспознанные поля полным путём. Раньше такое поле отбрасывалось молча: запрос с полем видимости, названным по-чужому, возвращал 201 и создавал репозиторий приватным. Правило действует только в собственном интерфейсе /api/v1; слои совместимости, SCIM, OIDC, Git LFS, протоколы реестров пакетов и протокол исполнителя принимают незнакомые поля как раньше.

Отказ разбора тела приходит общим конвертом. Было: 400 на сломанном JSON и 422 на разобранном не той формы, оба с англоязычным текстом библиотеки. Стало: 400 с кодом validation. Тело без Content-Type: application/json отвечает 415 тем же конвертом. Так же изменились отказы разбора параметров адреса и строки запроса.

Три намеренных ужесточения - там, где прежнее поведение отвечало успехом на невыполненное: PATCH /api/v1/users/{username} с is_admin или is_pro_seat без прав отвечает 403 вместо 200; PUT .../environments/{env} требует, чтобы имя среды в теле совпадало с именем в адресе; пустой sp_entity_id у поставщика SAML отвергается.

Настройка, которая перестала действовать

GITRIVER_RATE_LIMIT_DISABLED больше не работает. Замена - список освобождённых адресов: rate_limit_exempt_cidrs в конфигурации или GITRIVER_RATE_LIMIT_EXEMPT_CIDRS в окружении.

Установка, где переменная была задана, после обновления окажется под ограничением частоты. Сервер говорит об этом в журнале при старте.

Порядок действий

  1. Снимите резервную копию - до обновления, а не после.
  2. Проверьте четыре случая из первой таблицы.
  3. Если лицензия Pro и нужны корпоративные возможности - запросите файл активации Max заранее.
  4. Обновите образ, пакет или чарт и перезапустите. Миграции применятся сами.
  5. Проверьте журнал старта: там же будет сказано, если GITRIVER_RATE_LIMIT_DISABLED осталась в окружении.

Если обновление остановилось на пакетах NuGet

Идентификаторы NuGet регистронезависимы: Newtonsoft.Json и newtonsoft.json - один и тот же пакет, и клиент запрашивает его по адресу в нижнем регистре. Ранние версии GitRiver сохраняли имя как есть, поэтому в одном репозитории могли появиться две записи. Миграция, вводящая уникальность, такие записи не сливает сама - у одинаковых версий могут различаться файлы и метаданные - и останавливает обновление.

Найдите конфликтующие записи:

SELECT r.name AS repo, LOWER(p.name) AS package_id,
       ARRAY_AGG(p.name ORDER BY p.created_at) AS variants
FROM packages p
JOIN repositories r ON r.id = p.repo_id
WHERE p.type = 'nuget'
GROUP BY r.name, p.repo_id, LOWER(p.name)
HAVING COUNT(*) > 1;

Для каждой группы выберите написание, которое остаётся (обычно - опубликованное первым), и перенесите версии из остальных записей:

BEGIN;
UPDATE package_versions SET package_id = '<id остающегося пакета>'
 WHERE package_id = '<id лишнего пакета>';
DELETE FROM packages WHERE id = '<id лишнего пакета>';
COMMIT;

Если одна и та же версия опубликована в обеих записях, UPDATE завершится ошибкой package_versions_package_id_version_key: это две разные публикации одного номера версии. Решите, какая из них верна, удалите вторую (DELETE FROM package_versions WHERE id = ...) и повторите перенос.

После слияния перезапустите сервер - миграция применится.