Стан збирання

Ditana підтримує власне сховище pacman поверх Arch — 59 пакунків, повний перелік яких є в кожному завершеному прогоні. Прогін, що зупинився, показує те, до чого встиг дійти. Щоночі сервер збирання отримує рецепт кожного пакунка, вирішує, що потрібно перезібрати, і збирає це в чистому контейнері. Правило, яке визначає, що відбувається далі, — єдине, що тут має значення:

Якщо хоча б один пакунок не вдається зібрати або його джерела не вдається перевірити, не публікується нічого.

Не «решта публікується, а цей пакунок спробують зібрати завтра». Нічого. Сховище, з якого ви встановлюєте, — це або повний, узгоджений між собою набір, отриманий з одного прогону, або вчорашній повний, узгоджений між собою набір. Невелике сховище може це гарантувати; велике, що оновлюється пакунок за пакунком, — ні, і саме тому Ditana тримає своє сховище достатньо малим, щоб ручатися за нього як за єдиний набір.

Таке твердження варте рівно стільки, скільки докази на його користь, тому наведені нижче записи створює сам конвеєр, зокрема й про прогони, у яких нічого не опубліковано. Цей конвеєр — ditana-build, і він публічний: шлюз перевірки — це bin/pkgbuild-review-gate, а тест встановлення — bin/test-install-in-qemu.

Завантаження записів збирання…

Як далеко дійшов прогін

Кожен прогін проходить ті самі етапи, і його outcome показує, до якого з них він дійшов. Ось чотири стани, яким відповідають кольори вище:

outcome	Що це означає для вас
released	Саме це ви встановлюєте. Усі пакунки зібрано, усі підписи перевірено, і весь набір замінив сховище, з якого оновлюється ваша система.
in-testing	Зібрано й підписано; набір перебуває в окремому тестовому сховищі, поки його перевіряють. Ваша система й далі встановлює попередній випуск.
built	Сервер збирання завершив роботу, але він не має ключа підпису — підписування відбувається згодом на іншій машині. Поки що нічого не переміщено.
held-back	Щось не пройшло перевірку, тож не опубліковано взагалі нічого. Сховище, з якого ви встановлюєте, не змінено, і воно й далі узгоджене.

Лише released означає, що пакунки дійшли до вас. Інші три — це етапи на шляху до цього або зупинка.

Що сталося з кожним пакунком

У межах прогону кожен пакунок отримує один status:

status	Значення
current	Рецепт не змінювався відтоді, як було зібрано наявний пакунок, а для пакунка -git не змінився й коміт в оригінальному проєкті. Нічого робити не потрібно.
rebuilt	Джерела було отримано й перевірено на сервері, після чого пакунок зібрано в новому контейнері.
review-stopped	Рецепт змінився так, що на нього має подивитися людина. Прогін тут завершується.
build-failed	Пакунок не скомпілювався або не дав жодного артефакту. Прогін тут завершується.

Два останні статуси — причина, з якої прогін завершується як held-back: досить одного пакунка.

Чому прогін зупиняється

Більшість того, що перезбирає Ditana, — це сторонні рецепти з AUR, запаковані у сховище, якому користувачі довіряють через конфігурацію підписів pacman. AUR — це ланцюг постачання, і його вже атакували саме як ланцюг постачання: покинуті пакунки переймали й додавали до них шкідливі коміти, через що в серпні 2026 року AUR вимкнув перейняття пакунків і надсилання змін.

Тому кожен git pull у конвеєрі класифікується до того, як щось буде зібрано. Підвищення версії, коментарі, пробіли та контрольні суми, що супроводжують зміну версії, пропускаються. Зміна source=, url=, ревізії VCS, будь-чого всередині функції, install=, provides=, conflicts=, replaces= або validpgpkeys=, контрольна сума, що змінюється без зміни версії, нова залежність, якої pacman не знає, змінений або спорожнений рядок # Maintainer: — кожне з цього зупиняє прогін. Рецепт при цьому ніколи не виконується в оболонці (source): виконувати підозрілий файл — саме те, чого треба уникнути, тому аналіз статичний, а якщо він не впевнений, то блокує прогін.

Якщо зіставити з реальною історією пакунків за останні дванадцять місяців, це зупиняє прогін приблизно раз на три з половиною дні. Це не дефект, який треба прибрати налаштуванням; це ціна правила «все або нічого», сплачена наперед.

Деякі з рецептів, які перезбирає Ditana, узагалі не мають супровідника в AUR — їхній рядок # Maintainer: порожній. Саме тому спорожнений рядок супровідника зупиняє прогін, а не пропускається: покинутий рецепт — це саме той, який хтось може перейняти.

Чого це не перевіряє

Перевірка охоплює метадані пакування, а не вихідний код самих проєктів. Коли рецепт збирає з ревізії git, вміст цієї ревізії ніщо в цьому конвеєрі не перевіряє. Перевага Ditana над службою повторного збирання без перевірки реальна, але обмежена, і чітке визначення цієї межі — частина самого твердження.

Тест встановлення

Зібрати й підписати сховище — не те саме, що мати змогу встановити з нього систему. Між тестовим сховищем і випуском є ще один крок: сервер збирання встановлює саме це сховище у власну віртуальну машину, без участі людини, керуючись файлом відповідей на невеликому конфігураційному диску, — тим самим механізмом, який хостинг-провайдер використав би через PXE, тому жодні натискання клавіш не імітуються.

Мають виконатися дві умови, і записи показують, до якої з них дійшло.

етап	Що сталося
installing	Носій працює. Ще нічого не встановлено.
installed	Інсталятор дійшов до останнього перезавантаження.
booted	Встановлена система самостійно запустилася й відповіла на порту 22. Це успіх.

Ця різниця важлива, бо ці дві невдачі — різні помилки. Прогін, що зупинився на installing, створив сховище, з якого ніхто не може встановити систему. Прогін, що зупинився на installed, створив систему, яку записано правильно, але яка не запускається, — а це такий дефект, який не виявить жодне збирання.

Досягнення booted означає значно більше, ніж здається з назви. Завантажувач спрацював, initramfs знайшов та імпортував пул ZFS, systemd дійшов до багатокористувацького режиму, мережа стала активною, і запустилася служба. Щоб усе це влаштувати, у гостьову систему нічого не впроваджується: install-openssh типово ввімкнено, тож банер на порту 22 — справа рук самої встановленої системи.

Коли тест не вдається, записи містять знімок екрана гостьової системи в момент, коли тестове середовище припинило спроби. Інсталяційний носій нічого не пише в послідовну консоль після того, як його завантажувач передав керування, тож усе, що малює інсталятор, є лише на цьому екрані — інсталятор, що чекає на відповідь на запитання, видно там і не видно в жодному журналі.

Невдалий тест нічого не випускає. Пакунки залишаються в тестовому сховищі, а сховище, з якого ви встановлюєте, не змінюється.

Де зберігається ключ підпису

Машина, яка збирає, має підключ підпису, а не основний ключ.

Вона збирає, підписує цим підключем, вивантажує в тестове сховище, встановлює це сховище у віртуальну машину і публікує в робоче сховище, лише якщо встановлення вдалося. Тримати ключ поза сервером збирання конвеєр досі вміє, і саме так Ditana працювала до серпня 2026 року; від цього відмовилися, бо випуск, що залежить від тестового встановлення, має відбуватися на машині, яка щойно все зібрала, а розділення ставило між ними другу машину й ручний крок. Натомість підключ дає ось що: його можна відкликати й замінити окремо, він не може сертифікувати інші ключі, а відбиток, за яким перевіряють користувачі, ніколи не змінюється.

Це захищає ключ, а не пакунки: машина, що підписує, підписує те, що створив сервер збирання, не перевіряючи цього. Це запобігає тому, щоб машина, яка виконує чужі сценарії збирання, могла будь-коли дати підписати довільні дані.

Самостійна перевірка

Записи — це звичайний JSON, і генерує їх не цей вебсайт:

• /build-history/index.json — ковзний індекс найновіших прогонів.
• /build-history/<timestamp>.json — один файл на прогін: outcome, message, counts, об’єкт test-install, якщо прогін тестувався, і масив packages, елементи якого містять name, status, seconds, можливий detail і шляхи до журналів цього пакунка.
• Об’єкт test-install містить result, stage, до якого дійшла гостьова система, iso та answer-file, з якими її запускали, а якщо встановлення не вдалося, — шлях screenshot у /build-history/logs/<timestamp>/test-install/ зі знімком екрана гостьової системи в момент, коли тестове середовище припинило спроби.
• /build-history/logs/<timestamp>/<package>/ — те, що makepkg записав до журналу під час збирання цього пакунка, розбите за етапами (prepare, build, check, package). На кожен перезібраний пакунок у прогоні веде посилання з його рядка вище, і для пакунка, збирання якого не вдалося, журнал теж є — саме його й варто читати.

Імена серверів, адреси, шляхи та ім’я облікового запису збирання вилучаються із записів і журналів до того, як їх буде записано. Більше нічого не фільтрується; текст помилки, який ви бачите, — це той самий текст, який бачив конвеєр.

За якими ліцензіями

Кожен пакунок тут зібрано із загальнодоступного рецепта, у якому вказано його оригінальне джерело. На сторінці Ліцензування сказано, де знайти й те, й інше, і розглянуто єдиний випадок, коли сама ліцензія є предметом суперечки: пакунки ZFS, для яких Ditana розповсюджує вихідний код та інструменти простору користувача, але ніколи не скомпільований модуль ядра.