Справочник CLI digna 2026.06¶
2026-09-05
На этой странице описан полный набор команд, доступных в выпуске 2026.06 CLI digna, включая примеры использования и параметры.
Исполняемый файл называется digna.
Основы CLI¶
Обзор и синтаксис¶
CLI выпуска 2026.06 использует структурированную иерархию команд, построенную по категориям:
version и serve — одиночные команды без подкоманды:
Глобальные параметры¶
Следующие глобальные параметры действуют для всех команд:
--help,-h: Выводит справочную информацию по CLI либо по конкретной категории команд или подкоманде.--stacktrace: При сбое выводит полную цепочку ошибок вместо одного лишь сообщения верхнего уровня.
--stacktrace является глобальным параметром в строгом смысле: его нужно указывать до категории команд, а не после неё.
Флага --version не существует. Вместо него используйте команду version.
Предварительные требования¶
Большинству команд нужен читаемый и корректный файл config.toml; некоторым дополнительно требуется действующая лицензия. В следующей таблице зафиксировано, что загружает каждая категория команд, прежде чем что-либо сделать:
| Категория команд | Требуется config.toml | Требуется действующая лицензия |
|---|---|---|
version | нет | нет |
config check | нет (именно о нём команда и сообщает) | нет |
license check | нет | она и есть эта проверка |
crypt | да | нет |
serve | да | нет |
windows | нет (служба считывает его при запуске) | нет |
project | да | нет |
user | да | да |
inspection | да | да |
repo | да | да |
Там, где требуется лицензия, проверяются и её подпись, и срок действия, и команда прерывается, не затрагивая репозиторий, если хотя бы одна из этих проверок не пройдена.
Коды возврата¶
0: команда выполнена успешно.1: команда завершилась с ошибкой. Сообщение об ошибке записывается в stderr с префиксомError:.
help¶
Параметр --help выдаёт сведения о доступных категориях команд, подкомандах и параметрах:
-
Вывод общей справки:
-
Получение справки по конкретным категориям и командам:
Вывод включает: - Описание команды: Краткое изложение назначения команды. - Синтаксис: Обязательные и необязательные аргументы. - Параметры: Флаги и параметры, специфичные для данной команды.
version¶
Команда version выводит установленный выпуск digna. Она не читает конфигурацию и не проверяет лицензию, поэтому работает и в той установке, где файл config.toml или лицензия отсутствуют либо некорректны.
Версия выпуска не связана с версией схемы репозитория, о которой сообщает repo check.
Использование команды¶
Пример вывода¶
Управление конфигурацией¶
config check¶
Команда config check проверяет файл конфигурации (config.toml), убеждаясь, что все обязательные разделы и настройки присутствуют и правильно оформлены. Каждый раздел проверяется отдельно, поэтому неисправный раздел [app] не скрывает состояние раздела [repo].
Проверяются и отображаются следующие разделы:
App config([app])Repository config([repo])Base config([base])Logging config([logging])Encryption config([encryption])OIDC config(s)(oidc_clients) — необязательный; отсутствующий ключ проверку проходит, а присутствующий, но некорректно оформленный список — нет
Команда намеренно не загружает конфигурацию приложения так, как это делают остальные команды, чтобы иметь возможность диагностировать файл config.toml, который вообще не дал бы digna запуститься.
Использование команды¶
Параметры¶
--configpath,-c: Путь к файлу конфигурации или к каталогу, содержащемуconfig.toml(по умолчанию./config.toml).--json: Выводит отчёт о проверке в формате JSON. Имеет приоритет над--quiet.--quiet,-q: Подавляет отчёт и опирается исключительно на код возврата.
Пример¶
Проверить конкретный файл конфигурации и вывести результат в формате JSON:
Пример вывода¶
Configuration validation report (source: config.toml):
- App config: OK
- Repository config: OK
- Base config: OK
- Logging config: OK
- Encryption config: FAILED
missing field `aes_gcm_key`
- OIDC config(s): OK
Overall: FAILED
Отсутствующий файл или синтаксическая ошибка TOML не оставляют ничего, что можно было бы проверять раздел за разделом, и сообщаются как единственная ошибка вместо отчёта — независимо от --quiet или --json.
Управление репозиторием¶
repo check¶
Команда repo check проверяет подключение к базе данных, а также установку и версию репозитория. Она завершается с ошибкой, если настроенная схема не существует либо существует, но не содержит репозитория digna.
Сообщаемая версия — это версия схемы репозитория, которая версионируется отдельно от выпуска digna, выводимого командой version.
Использование команды¶
Пример вывода¶
repo install¶
Команда repo install устанавливает новый репозиторий digna в схему, заданную в config.toml, создавая все необходимые последовательности, таблицы, индексы, ограничения и первоначальные записи.
Сама схема этой командой не создаётся — она должна существовать заранее. Команда также отказывается выполняться, если репозиторий в этой схеме уже установлен, и указывает на repo upgrade, если установлена более старая версия.
Использование команды¶
Пример вывода¶
Installing repo version 3.0.0
✅ Sequences created.
✅ Tables and Indices created.
✅ Constraints created.
✅ Records inserted.
✅ Repo version 3.0.0 successfully installed.
repo upgrade¶
Команда repo upgrade применяет миграции схемы базы данных, чтобы привести существующий репозиторий к версии, ожидаемой установленным выпуском. Обновления применяются по одному переходу между версиями за раз вдоль фиксированного пути обновления, и каждый завершённый переход фиксируется в репозитории.
Если репозиторий уже находится в ожидаемой версии, команда сообщает, что обновление не требуется, и не вносит изменений.
Использование команды¶
Пример вывода¶
Upgrading from 2.3.1 to 2.3.2...
Upgrading from 2.3.2 to 3.0.0...
✅ Repo successfully upgraded to version 3.0.0.
repo prune¶
Команда repo prune удаляет строки, пережившие проект или источник данных, к которому они относились. При удалении проекта или источника данных удаляется сам объект, но его профили, прогнозы, статусы и счётчики строк остаются — это сознательный компромисс, поскольку удаление, которое заодно очищало бы эти таблицы, заставляло бы пользователя ждать. repo prune — это служебный проход, который их очищает, и его можно безопасно запускать в любое время: он удаляет только строки, проект или источник данных которых больше не существует.
Строки, записанные серверной частью на Python в таблицы, которые текущий выпуск больше не использует, не затрагиваются.
Использование команды¶
Параметры¶
--dry-run: Сообщает, что было бы удалено, ничего не удаляя.
В списке выводятся только таблицы с осиротевшими строками. Если таких нет, команда сообщает No orphaned rows found. и завершает работу.
Пример¶
Пример вывода¶
"check" 29342
check_profile 29342
check_prediction 29342
check_status 29342
column_status 32
inspection_query 253
---------------------------------------------
total 117854
✅ Removed 117854 orphaned row(s).
Чтобы увидеть тот же отчёт, ничего не удаляя:
Количество строк совпадает; отличается только заключительная строка:
Управление шифрованием¶
crypt gen-key¶
Команда crypt gen-key генерирует новый ключ шифрования AES-GCM для использования в качестве ключа шифрования в config.toml. Загружаемый файл config.toml уже должен присутствовать, хотя сгенерированный ключ от него и не зависит.
Использование команды¶
Пример вывода¶
crypt encrypt¶
Команда crypt encrypt шифрует строку (например, пароль к базе данных) с помощью ключа AES-GCM, заданного в config.toml, и выводит шифротекст.
Использование команды¶
Аргументы¶
- VALUE: Открытая строка, которую нужно зашифровать (обязательный).
Пример¶
crypt decrypt¶
Команда crypt decrypt расшифровывает строку, зашифрованную алгоритмом AES-GCM, с помощью ключа, заданного в config.toml, и выводит открытый текст.
Использование команды¶
Аргументы¶
- VALUE: Зашифрованная строка, которую нужно расшифровать (обязательный).
Пример¶
Управление пользователями¶
user add¶
Команда user add создаёт новую учётную запись пользователя в репозитории digna. Команда завершается с ошибкой, если пользователь с указанным адресом электронной почты уже существует.
Использование команды¶
Аргументы¶
- EMAIL: Адрес электронной почты пользователя (обязательный).
- PASSWORD: Первоначальный пароль пользователя (обязательный).
- DISPLAY_NAME: Полное отображаемое имя пользователя (обязательный).
Параметры¶
--admin,-a: Создаёт пользователя с правами администратора (суперпользователя).
Пример¶
Создание учётной записи администратора:
Пример вывода¶
user list¶
Команда user list выводит всех зарегистрированных пользователей в виде таблицы с идентификатором, адресом электронной почты, отображаемым именем и признаком администратора.
Использование команды¶
Пример вывода¶
ID EMAIL DISPLAY NAME ADMIN
-----------------------------------------------------------------------------------------------
42 jdoe@example.com John Doe false
43 admin@example.com Admin User true
user modify¶
Команда user modify обновляет отображаемое имя и права администратора существующей учётной записи пользователя, определяемой по адресу электронной почты.
И отображаемое имя, и признак администратора записываются всегда. --admin — это переключатель, а не значение: если его не указать, права администратора отзываются, поэтому указывайте его всякий раз, когда пользователь должен сохранить или получить их.
Использование команды¶
Аргументы¶
- EMAIL: Адрес электронной почты изменяемого пользователя (обязательный).
- DISPLAY_NAME: Обновлённое отображаемое имя (обязательный).
Параметры¶
--admin,-a: Предоставляет права администратора. Не указывайте, чтобы отозвать их.--valid-until,-v: Принимается ради совместимости, но в настоящее время не применяется. Его передача выводит предупреждение и ничего не меняет.
Пример¶
Пример вывода¶
user modify-pwd¶
Команда user modify-pwd обновляет пароль существующей учётной записи пользователя.
Использование команды¶
Аргументы¶
- EMAIL: Адрес электронной почты пользователя, пароль которого нужно обновить (обязательный).
- PASSWORD: Новый пароль (обязательный).
Пример¶
user delete¶
Команда user delete удаляет учётную запись пользователя из системы.
Использование команды¶
Аргументы¶
- EMAIL: Адрес электронной почты удаляемого пользователя (обязательный).
Пример¶
Управление проектами и источниками данных¶
project list¶
Команда project list выводит все доступные в репозитории проекты с их идентификатором, именем и описанием.
Использование команды¶
Пример вывода¶
ID NAME DESCRIPTION
------------------------------------------------------------------------------------------------------
7 ProjectA Sales data quality
8 ProjectB Finance data quality
project list-ds¶
Команда project list-ds выводит все источники данных, связанные с указанным проектом, показывая их идентификатор, имя, вид, схему и имя таблицы.
Использование команды¶
Аргументы¶
- PROJECT_NAME: Имя проекта, источники данных которого нужно вывести (обязательный). Имя должно совпадать точно.
Пример¶
Пример вывода¶
ID NAME KIND SCHEMA TABLE
-------------------------------------------------------------------------------------------------------------
101 orders Table sales orders
102 customers Table sales customers
project export-ds¶
Команда project export-ds экспортирует источники данных проекта в документ JSON.
Если не указан ни --table-name, ни --table-id, экспортируются все источники данных проекта.
Использование команды¶
Аргументы¶
- PROJECT_NAME: Имя проекта, из которого экспортируются источники данных (обязательный).
Параметры¶
--table-name,-n: Имена экспортируемых источников данных. Можно указать несколько имён через пробел.--table-id,-i: Идентификаторы экспортируемых источников данных. Можно указать несколько идентификаторов через пробел.--exportfile,-f: Путь, по которому сохраняются экспортированные источники данных (по умолчанию:data_sources_export.json).
Пример¶
Экспортировать все источники данных из ProjectA:
Экспортировать отдельные таблицы:
Пример вывода¶
project import-ds¶
Команда project import-ds импортирует источники данных из файла экспорта в целевой проект и сообщает по каждому объекту, что было создано, обновлено или пропущено.
Использование команды¶
Аргументы¶
- PROJECT_NAME: Имя целевого проекта, в который выполняется импорт (обязательный).
- EXPORT_FILE: Путь к файлу экспорта в формате JSON (обязательный).
Параметры¶
--output-file,-o: Файл, в который записывается отчёт об импорте. Без него отчёт выводится в stdout.--output-format,-f: Формат отчёта об импорте —table,jsonилиcsv(по умолчанию:table).
Пример¶
Получить отчёт в машиночитаемом виде:
digna project import-ds ProjectB my_export.json --output-format json --output-file import_report.json
Отчёт охватывает четыре уровня объектов — источник данных, определение набора данных, атрибут и правило проверки — и для каждого содержит действие импорта, результат, идентификатор полученного объекта и любые дополнительные сведения.
project plan-import-ds¶
Команда project plan-import-ds показывает предварительный план импорта источников данных в целевой проект: какие объекты были бы созданы, обновлены или пропущены, — ничего при этом не изменяя. Она принимает тот же файл экспорта и те же параметры отчёта, что и project import-ds, и дополнительно указывает номер шага для каждого запланированного объекта.
Использование команды¶
Аргументы¶
- PROJECT_NAME: Имя целевого проекта (обязательный).
- EXPORT_FILE: Путь к файлу экспорта (обязательный).
Параметры¶
--output-file,-o: Файл, в который записывается план импорта. Без него план выводится в stdout.--output-format,-f: Формат плана импорта —table,jsonилиcsv(по умолчанию:table).
Пример¶
project cleanup¶
Команда project cleanup удаляет результаты инспекций, накопленные проектом за диапазон дат, — профили, прогнозы, счётчики строк и все статусы проверок, атрибутов, наборов данных и источников данных. Она удаляет ровно то, что записала инспекция за эти даты, поэтому после этого диапазон можно проинспектировать заново, чтобы восстановить результаты.
История Timeliness и Schema Tracker не удаляется: она фиксирует то, что digna наблюдала в определённый день, а не производный от этого результат, поэтому очистка прошедшего диапазона дат её не затрагивает.
Каждый источник данных очищается в отдельной транзакции, поэтому прерванный запуск оставляет источники данных целыми, а не очищенными наполовину.
Использование команды¶
Аргументы¶
- PROJECT_NAME: Проект для очистки (обязательно). Один проект за один вызов.
- FROM_DATE: Первая дата, за которую удаляются результаты,
YYYY-MM-DD(обязательно). - TO_DATE: Последняя дата, за которую удаляются результаты, включительно,
YYYY-MM-DD(обязательно).
Параметры¶
--table-name,-n: Ограничивает очистку указанными источниками данных. Можно указать несколько имён через пробел.--table-filter: Ограничивает очистку источниками данных, имя которых содержит эту подстроку.--dry-run: Выводит список источников данных, которые были бы очищены, ничего не удаляя.--timing: Показывает, сколько времени заняла очистка.
--table-name и --table-filter объединяются по ИЛИ — источник данных очищается, если он назван по имени или если совпадает подстрока. Если ни один источник данных не подходит, команда завершается с ошибкой, а не сообщает об успехе очистки, которая ничего не сделала.
Пример¶
С ограничением одним источником данных:
Пример вывода¶
Cleaning up project 'ProjectA' from 2026-01-01 to 2026-06-30:
- Table1
- Table2
- Table3
✅ Cleaned up 3 data source(s).
Чтобы увидеть, какие источники данных были бы очищены, ничего не удаляя:
Каждая строка помечена, поэтому пробный запуск невозможно спутать с настоящим:
Cleaning up project 'ProjectA' from 2026-01-01 to 2026-06-30:
- Table1 (dry run, nothing removed)
- Table2 (dry run, nothing removed)
- Table3 (dry run, nothing removed)
Dry run - 3 data source(s) would be cleaned up.
Управление инспекциями¶
inspection run¶
Команда inspection run создаёт запрос на инспекцию для проекта и диапазона дат, а затем — в зависимости от указанных параметров — либо ожидает его выполнения, либо сразу завершается, либо выполняет инспекцию в собственном процессе.
Три режима выполнения:
- По умолчанию (без флага): запрос ставится в очередь для серверной части, а CLI опрашивает его каждые две секунды, выводя ход выполнения задач, пока инспекция не перейдёт в конечное состояние. Требуется запущенный
digna serve, иначе запрос никто не подхватит. --async-mode: запрос ставится в очередь, а его идентификатор выводится немедленно. Для наблюдения используйтеinspection status.--bypass-backend: инспекция выполняется самим процессом CLI и не ставится в очередь, поэтому запущенный сервер не нужен.
--async-mode и --bypass-backend являются взаимоисключающими.
В любом режиме команда завершается с ненулевым кодом возврата, если инспекция не была завершена успешно.
Использование команды¶
Аргументы¶
- PROJECT_NAME: Имя целевого проекта (обязательный). Имя должно совпадать точно.
- START_DATE: Начальная дата диапазона в формате
YYYY-MM-DD(обязательный). - END_DATE: Конечная дата диапазона в формате
YYYY-MM-DD(обязательный).
Параметры¶
--table-name: Ограничивает инспекцию одним источником данных проекта, заданным именем этого источника. Без него инспектируются все источники данных проекта.--async-mode: Ставит инспекцию в очередь и выводит идентификатор запроса вместо ожидания. Нельзя сочетать с--bypass-backend.--bypass-backend: Выполняет инспекцию непосредственно в процессе CLI вместо постановки её в очередь для серверной части. Нельзя сочетать с--async-mode.
Пример¶
Отправить асинхронную инспекцию:
Проинспектировать один источник данных:
Пример вывода¶
Режим по умолчанию:
Inspection request submitted. Waiting for completion (Request ID: 1024)...
Progress: 3/10 tasks completed (0 failed)
Progress: 10/10 tasks completed (0 failed)
Inspection completed successfully.
Inspection successful for project: ProjectA
Асинхронный режим:
inspection status¶
Команда inspection status запрашивает состояние и ход выполнения задач запроса на инспекцию по его идентификатору.
Использование команды¶
Аргументы¶
- INSPECTION_REQUEST_ID: Числовой идентификатор запроса на инспекцию (обязательный).
Пример¶
Пример вывода¶
Inspection Request ID: 1024
Status: Running
Project ID: 7
Date Range: 2024-01-01 to 2024-01-31
Progress: 3/10 tasks completed (0 failed)
inspection abort¶
Команда inspection abort запрашивает отмену выполняющихся или ожидающих запросов на инспекцию. Она записывает событие остановки для каждого затронутого запроса; действует по нему серверная часть, поэтому прерывание — это просьба остановиться, а не немедленное завершение.
Использование команды¶
Аргументы¶
- INSPECTION_REQUEST_ID: Идентификатор прерываемого запроса на инспекцию. Обязателен, если не указан
--killall.
Параметры¶
--killall: Прерывает все выполняющиеся и ожидающие запросы на инспекцию. Имеет приоритет над идентификатором запроса, указанным вместе с ним.
Пример¶
Прервать конкретный запрос:
Прервать все активные и стоящие в очереди инспекции:
Пример вывода¶
--killall сообщает о том, что было сделано; прерывание одного запроса не выводит ничего и сообщает об успехе своим кодом возврата.
Управление лицензиями¶
license check¶
Команда license check проверяет файл license.toml, сверяя его подпись с открытым ключом, поставляемым вместе с установкой, и убеждаясь, что срок его действия не истёк. Она не читает конфигурацию приложения, поэтому работает и до того, как настроен config.toml.
Использование команды¶
Пример вывода¶
Недействительная подпись и истёкшая лицензия сообщаются как разные ошибки, обе с кодом возврата 1.
Сервер и фоновые службы¶
serve¶
Команда serve запускает сервер REST API digna вместе с фоновым планировщиком инспекций и менеджером инспекций. При запуске она также помечает как неуспешные все инспекции, которые репозиторий всё ещё числит выполняющимися, поскольку от предыдущего процесса ничего сохраниться не могло.
Команда работает на переднем плане, пока её не остановят.
Использование команды¶
Параметры¶
--address: Сетевой адрес, к которому привязывается сервер API (по умолчанию:127.0.0.1).--port: Номер порта для прослушивания (по умолчанию:8000).
Пример¶
Пример вывода¶
Управление службой Windows¶
Доступно только в Windows. Эти команды регистрируют серверную часть digna в диспетчере служб Windows и управляют ею; сама служба выполняет serve в фоновом режиме. Каждую команду необходимо запускать из командной строки с повышенными правами, и каждая принимает --name, чтобы можно было обращаться к службе, зарегистрированной под нестандартным именем.
windows install¶
Команда windows install регистрирует digna как службу Windows.
Указанные здесь адрес и порт записываются в регистрацию службы, и именно к ним служба привязывается — они не считываются из config.toml. Чтобы изменить их впоследствии, удалите службу и установите её заново.
Использование команды¶
Параметры¶
--name: Имя, под которым регистрируется служба (по умолчанию:digna).--display-name: Имя, отображаемое в services.msc (по умолчанию:digna).--description: Описание, отображаемое в services.msc (по умолчанию:digna data quality backend).--address: Адрес, к которому служба привязывает свой API (по умолчанию:127.0.0.1).--port: Порт, к которому служба привязывает свой API (по умолчанию:8000).--working-dir: Каталог с файламиconfig.tomlиlicense.toml, который служба делает своим рабочим каталогом (по умолчанию: каталог исполняемого файлаdigna).--start-type: Когда запускается служба —autoвместе с Windows,manualтолько по запросу,disabledзарегистрирована, но отказывается запускаться (по умолчанию:auto).--account: Учётная запись, от имени которой выполняется служба, напримерDOMAIN\userили.\user(по умолчанию:LocalSystem).--password: Пароль учётной записи--account.
Пример¶
Регистрация под вторым именем с запуском от имени доменной учётной записи:
digna windows install --name digna-test --display-name "digna (test)" --account DOMAIN\svc_digna --password <password>
windows start¶
Команда windows start запускает зарегистрированную службу.
Использование команды¶
Параметры¶
--name: Имя, под которым зарегистрирована служба (по умолчанию:digna).
windows stop¶
Команда windows stop останавливает работающую службу. Останавливайте службу перед заменой любого файла приложения.
Использование команды¶
Параметры¶
--name: Имя, под которым зарегистрирована служба (по умолчанию:digna).
windows uninstall¶
Команда windows uninstall отменяет регистрацию службы. Сначала остановите её.
Использование команды¶
Параметры¶
--name: Имя, под которым зарегистрирована служба (по умолчанию:digna).