Перейти к содержанию
zoryn/ maintainer-assistant

zoryn submit

Полный цикл сборки: commit, tag, push и отправка на сборку — одной командой.

Использование

zoryn submit [-B repo] [--with spec] [--replace[=TASK_ID[:N]]]
             [--run] [--no-run] [--test-only] [--commit]
             [--dry-run] [--skip-check] [--batch-pkgs=PKGS]
             [--allow-overwrite-tag] [-d]

По умолчанию создаёт задание, но не запускает его (режим test-only). --run запускает сборку, --commit — публикация вместо test-only. Поведение по умолчанию настраивается в ~/.zoryn:

[submit]
run = true
test_only = false

Если предыдущий коммит имеет тот же version-release subject (например, при повторе submit), коммиты автоматически объединяются.

С -B отправляет в указанный репозиторий и автоматически добавляет зависимости от задач в более свежих репозиториях. Несколько репозиториев через запятую (sisyphus,p11) — каждая последующая отправка зависит от предыдущей задачи.

Опции

  • -B, --branch <repo> — целевой репозиторий (по умолчанию: sisyphus), поддерживает TAB-дополнение.
  • --with <spec> — добавить в существующее задание с позиционированием. Синтаксис:
    • PKG — найти задание, добавить в конец.
    • ^PKG — перед PKG.
    • PKG: — после PKG.
    • TASK_ID — в конец задания.
    • TASK_ID:REF — после REF.
    • TASK_ID^REF — перед REF.
    • PKG — имя пакета или pkg.git=tag (ищет задание с этим конкретным сабтаском — полезно, когда один пакет встречается в нескольких заданиях).
    • REF — имя пакета, номер сабтаска или pkg.git=tag.
    • Если такой же тэг уже есть, автоматически заменяет. Если пакет есть с другим тэгом, запрашивает действие.
  • --replace[=TASK_ID[:N]] — заменить сабтаск. Без аргумента: автоматический поиск по текущему пакету (с подтверждением). С TASK_ID — в указанном задании. С TASK_ID:N — указанный сабтаск. С мультибранчевым -B sisyphus,p11 и без TASK_ID автопоиск выполняется отдельно для каждой ветки и сабтаск заменяется в задании каждой ветки; --replace=TASK_ID указывает одно задание и не сочетается с несколькими ветками.
  • --run — запустить задание после создания/изменения.
  • -n, --no-run — не запускать (переопределяет конфиг).
  • --test-only — пометить как тестовое (без публикации).
  • --commit — пометить для публикации (противоположно --test-only).
  • --dry-run — предпросмотр действий без выполнения.
  • --skip-check — пропустить валидацию spec-файла (см. zoryn check spec).
  • --batch-pkgs=PKGS — отправить только указанные batch-значения.
  • --allow-overwrite-tag — принудительно пересоздать существующий локальный тэг, минуя проверки gears/ancestor.

Безопасность пересоздания тэга

По умолчанию submit отказывается перезаписывать существующий локальный тэг, указывающий на другой коммит, если выполнено хотя бы одно из условий:

  • тэг уже опубликован в git.altlinux.org/gears/<X>/<pkg>.git (неизменяемая история сборок), либо
  • коммит тэга не является предком HEAD (вероятно, тэг принадлежит другой ALT-ветке, которую вы ведёте в отдельной git-ветке).

В первом случае увеличьте release (alt0.c10f2.2), во втором — переключитесь на нужную ветку или удалите локальный тэг вручную, если уверены. Флаг --allow-overwrite-tag снимает обе проверки для ситуаций, когда вы знаете, что это безопасно (например, чистка устаревшего тэга от прерванной попытки).

Исключение для новых пакетов. Если репозиторий gears заведомо отсутствует (ls-remote завершился с кодом 128 — «репозиторий не найден»), и пакет неизвестен RDB (никогда не собирался в Sisyphus), проверка на предка пропускается автоматически, а локальный тэг пересоздаётся с предупреждением. Логика: удалённого потребителя ещё не существует, поэтому любой предсуществующий локальный тэг по построению устарел от прошлой локальной попытки.

--replace подразумевает --allow-overwrite-tag. Замена незавершённой подзадачи после git commit --amend или git rebase законно перемещает тэг на новый коммит. submit --replace включает перезапись автоматически и печатает приглушённое уведомление об этом. Проверка неизменяемости gears остаётся: уже опубликованная задача не появится в выборке --replace, так как task ls показывает только открытые задачи.

task batch --refresh всегда перезаписывает локальный тэг (в этом и смысл refresh), поэтому --allow-overwrite-tag имеет значение только при обычных submit, не refresh.

Модули ядра

При запуске в репозитории шаблона kernel-module zoryn submit автоматически определяет шаблонную структуру и создаёт specsubst-тэги для каждого флейвора ядра — заменяя ручной процесс km-create-tag из kernel-build-tools.

Условия автоопределения — необходимо выполнение всех трёх:

  • Текущая ветка соответствует шаблону template/<module>/<dist> (например, template/zfs/sisyphus).
  • В .gear/rules объявлено specsubst: kflavour karch.
  • В корне репозитория есть файл kernel-modules-<module>.spec.

При обнаружении шаблона submit создаёт один тэг на каждый флейвор ядра в формате <dist>/kernel-modules-<module>-<flavour>-<version>-<release>. Каждый тэг содержит два specsubst-заголовка:

X-gear-specsubst: kflavour=<flavour>
X-gear-specsubst: karch=<karch>

karch (архитектуры, для которых собирается модуль) определяется так: явное совпадение glob-шаблона в .gear/km-karch, иначе — архитектуры, для которых собрано само ядро (из Repoteka, чтобы модуль не собирался там, где его ядра нет), иначе значение по умолчанию %ix86 x86_64 aarch64. NVR определяется через gear --describe.

Источники флейворов

Флейворы берутся из первого непустого источника:

  1. -k / --kernel FLAVOUR — явный список. Можно повторять и перечислять через запятую: -k std-def,un-def или -k std-def -k un-def. TAB-дополнение из исходных пакетов kernel-image-* в Repoteka.
  2. Файл .gear/kflavours — по одному флейвору на строку, строки с # игнорируются.
  3. Существующие сборки модуля — флейворы, для которых в целевой ветке уже есть бинарный пакет kernel-modules-<module>-<flavour>. Это поведение по умолчанию: submit пересобирает только те ядра, для которых модуль уже собран, а не все kernel-image-*. Если сборок модуля ещё нет, необходимо указать -k.

Опции для модулей ядра

  • -k, --kernel <FLAVOUR> — собрать для указанного флейвора (повторяемый и через запятую, TAB-дополнение из Repoteka).
  • --no-kernel-module — отключить автоопределение даже при наличии шаблонной структуры.
  • --dry-run — показать предполагаемые имена тэгов без их создания.

Все тэги флейворов становятся подзадачами одного задания сборки — так же, как при batch-отправке.

--with <spec> добавляет все тэги флейворов в существующее задание (например, в задание самого ядра): zoryn submit -k std-def -k un-def --with zfs.

--replace тоже поддерживается: каждый новый тэг флейвора заменяет в целевом задании подзадачу с тем же флейвором (а если сборки этого флейвора ещё нет — добавляет её), не трогая остальные. Эта замена по значению — общая с batch-отправками specsubst (репозиторий с несколькими тэгами). Опция --batch-pkgs в режиме модулей ядра не используется.

# в репозитории шаблона kernel-module, на ветке template/zfs/sisyphus
zoryn submit -k std-def -k un-def

# добавить пересборки модуля в задание, где уже есть zfs
zoryn submit -k std-def -k un-def --with zfs

# предпросмотр без создания тэгов
zoryn submit --dry-run

Ядро

Само ядро тоже определяется автоматически: репозиторий, в котором .gear/rules объявляет specsubst: kflavour (без karch), а Name: в спеке содержит плейсхолдер @kflavour@ (например, Name: kernel-image-@kflavour@). Без этого режима gear-create-tag завершается ошибкой specsubst variable "kflavour" is not defined in the tag message.

submit создаёт один тэг на флейвор в формате kernel-image-<flavour>-<version>-<release> с заголовком X-gear-specsubst: kflavour=<flavour> — в том же формате, что и официальные gear-репозитории kernel-image-*. Version и Release берутся из спека.

Флейвор берётся из первого непустого источника:

  1. -k / --kernel FLAVOUR — явно, повторяемый и через запятую.
  2. Ключ kflavour в секции [specsubst] файла .gear/version-up (через запятую).
  3. Префикс ветки <flavour>/<dist> — распознаётся только когда <dist> — известная ветка ALT, так что тематическая ветка вроде fix/typo никогда не станет флейвором. На ветке for-vm/sisyphus флейвор — for-vm, а часть <dist> становится целью -B по умолчанию.

--no-kernel-module отключает и это автоопределение, а явный [batch]-конфиг со значениями в .gear/version-up имеет приоритет над ним (репозиторий тогда отправляется через batch-путь specsubst). --batch-pkgs и несколько репозиториев в -B в kernel-режиме отклоняются. --dry-run, --with и позначное --replace работают так же, как в режиме модулей ядра.

# на ветке for-vm/sisyphus: тэг kernel-image-for-vm-<ver>-<rel>, цель sisyphus
zoryn submit

# явный флейвор
zoryn submit -k 6.18

# или зафиксировать в .gear/version-up
# [specsubst]
# kflavour = "for-vm"

Примеры

zoryn submit                     # создать (не запускать, test-only)
zoryn submit --run               # создать и запустить тест
zoryn submit --run --commit      # создать и запустить на публикацию
zoryn submit -B p11              # в p11 с --deps от sisyphus
zoryn submit -B sisyphus,p11     # сначала в sisyphus, потом p11 с --deps
zoryn submit --with libva        # в задание с libva (в конец)
zoryn submit --with ^libva       # перед libva
zoryn submit --with libva:       # после libva
zoryn submit --with 12345        # в конец задания 12345
zoryn submit --with 12345^libva  # перед libva в 12345
zoryn submit --with 12345:libva  # после libva в 12345
zoryn submit --replace           # заменить сабтаск (с подтверждением)
zoryn submit --replace --run     # заменить и запустить
zoryn submit --replace=12345     # в конкретном задании
zoryn submit --replace=12345:3   # конкретный сабтаск
zoryn submit --replace -B sisyphus,p11  # заменить в задании каждой ветки (автопоиск по каждой)
zoryn submit --no-run            # явно не запускать
zoryn submit --dry-run           # предпросмотр

При отправке в стабильные ветки причина сборки определяется автоматически (new version, bugfix release, new package). Если в changelog найдены CVE между версиями, причина дополняется пометкой «with security fixes».