К содержимому
gtcnsl
EN RU

Апгрейды и self-update

gtcnsl обновляет себя с download-хоста с проверкой SHA-256 и снапшотом для отката. Gitea двигается вперёд так же, как вы её ставили — после бэкапа.

Актуально для v1.3.0

Обновить сам gtcnsl

# доступен ли новый релиз? (без записи, --yes не нужен)
gtcnsl self-update --dry-run

# обновиться до последнего релиза
gtcnsl self-update --yes

# зафиксировать конкретную версию
gtcnsl self-update --to v0.6.1 --yes

Под капотом он определяет последний тег по versions.json, скачивает https://dl.gtcnsl.ru/<tag>/gtcnsl-<tag>-linux-<arch>, сверяет с checksums.txt (SHA-256), снапшотит работающий бинарник, атомарно меняет его, затем запускает gtcnsl --version для подтверждения — откатываясь автоматически, если проверка не прошла.

Откатить gtcnsl

gtcnsl self-update --rollback --yes

Восстанавливает бинарник, заменённый последним self-update. (--rollback нельзя сочетать с --to или --dry-run.)

i
Выберите зеркало
Загрузки по умолчанию идут с https://dl.gtcnsl.com. Перенаправьте через --dl-host или переменную $GTCNSL_DLHOST; https://dl.gtcnsl.ru — идентичное зеркало.

Двигать Gitea вперёд

gtcnsl gitea upgrade [--to <v>] [--yes] — короткая команда для уже установленной Gitea: она чисто отказывает, если ставить пока нечего, а иначе едет по тому же пути обновления на месте, что и gitea install --to <version> всегда использовала: пути берутся из живой установки (обновление никогда не переносит данные), --data-dir/--log-dir, противоречащие живой установке, отклоняются, а юнит gitea.service, написанный не gtcnsl, сохраняется байт-в-байт — только замена бинарника и перезапуск; передайте --rewrite-unit, если сознательно хотите шаблон gtcnsl. Если в том же шаге нужны дополнительные флаги — обращайтесь напрямую к gitea install --to. TUI показывает ту же детекцию баннером обновления с живыми путями в полях.

Если после замены бинарника что-то ломается — деплой юнита, рестарт или health-check после апгрейда — gtcnsl автоматически восстанавливает предыдущий бинарник Gitea и перезапускает сервис; после неудачного апгрейда хост никогда не остаётся без работающей Gitea.

Данные Gitea сохраняются при замене бинарника, но сначала сделайте снапшот, чтобы можно было вернуться в заведомо рабочее состояние:

gtcnsl backup
gtcnsl gitea upgrade --to v1.27.0 --yes
gtcnsl doctor   # убедиться, что юнит поднялся и здоров

gtcnsl backup снапшотит бинарник Gitea, app.ini, secrets.ini, дерево custom/, а также — если установлен раннер — его регистрацию .runner, config.yaml и юнит gitea-runner.service, всё в /var/lib/gtcnsl/backups/<id>/. Список и восстановление:

gtcnsl backup list
gtcnsl restore <backup-id> --yes

restore снапшотит живые файлы, останавливает Gitea (и раннер, если в бэкапе есть его состояние), подставляет бэкап, рестартит и проверяет здоровье — отменяя себя, если Gitea не поднимается. Бэкап, сделанный до этого релиза, восстанавливается точно так же, как раньше — просто без пунктов раннера, которых в нём нет.

!
Перед скачком читайте changelog
Gitea запускает свои миграции при первом старте после апгрейда; перепрыгивать сразу несколько минорных версий рискованнее. Бэкапьте, двигайтесь по шагу за раз и проверяйте gtcnsl doctor после каждого.

Двигать раннер вперёд

gtcnsl runner upgrade [--to <v>] [--yes] — аналог gitea upgrade для раннера: чисто отказывает, если раннер не установлен, иначе меняет бинарник на месте и перезапускает сервис. Команда следует фактам живого юнита — путь к бинарнику, рабочая директория, даже устаревшее имя act_runner.service из времён до переименования в v0.2 — вместо того чтобы полагаться на канонический layout gtcnsl, так что усыновлённый или перенесённый раннер (gtcnsl runner adopt) тоже обновляется корректно. Как и gitea upgrade, при неудачной замене gtcnsl автоматически восстанавливает предыдущий бинарник раннера и перезапускает сервис.

gtcnsl runner upgrade --to v2.1.0 --yes

Дальше

Если после апгрейда что-то не так — начните с «Решение проблем и FAQ».