Довідник CLI digna 2026.06¶

2026-09-05

На цій сторінці описано повний набір команд, доступних у випуску 2026.06 CLI digna, разом із прикладами використання та параметрами.

Виконуваний файл має назву digna.

Основи CLI¶

Огляд і синтаксис¶

CLI випуску 2026.06 використовує структуровану ієрархію команд, побудовану за категоріями:

digna [GLOBAL_OPTIONS] <COMMAND_CATEGORY> <SUBCOMMAND> [OPTIONS] [ARGUMENTS]

version і serve — це окремі команди без підкоманди:

digna [GLOBAL_OPTIONS] <COMMAND> [OPTIONS] [ARGUMENTS]

Глобальні параметри¶

Наведені нижче глобальні параметри діють для всіх команд:

--help, -h: Показує довідкову інформацію про CLI або про конкретну категорію команд чи підкоманду.
--stacktrace: У разі помилки показує весь ланцюжок помилок замість самого лише повідомлення верхнього рівня.

--stacktrace є глобальним параметром у строгому сенсі: його потрібно вказувати перед категорією команд, а не після неї.

digna --stacktrace repo check     # correct
digna repo check --stacktrace     # rejected: unknown argument

Прапорця --version не існує. Натомість скористайтеся командою version.

Передумови¶

Більшість команд потребують придатного до читання й коректного файлу config.toml; деякі додатково вимагають чинної ліцензії. У наведеній нижче таблиці зафіксовано, що завантажує кожна категорія команд, перш ніж що-небудь зробити:

Категорія команд	Потрібен `config.toml`	Потрібна чинна ліцензія
`version`	ні	ні
`config check`	ні (саме про нього команда й звітує)	ні
`license check`	ні	вона і є цією перевіркою
`crypt`	так	ні
`serve`	так	ні
`windows`	ні (служба зчитує його під час запуску)	ні
`project`	так	ні
`user`	так	так
`inspection`	так	так
`repo`	так	так

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

Коди завершення¶

0: команда виконана успішно.
1: команда завершилася помилкою. Повідомлення про помилку записується до stderr із префіксом Error:.

help¶

Параметр --help надає відомості про доступні категорії команд, підкоманди та параметри:

Показ загальної довідки:
```
digna --help
```
Отримання довідки для конкретних категорій і команд:
```
digna user --help
digna user add --help
```

Вивід містить: - Опис команди: Стислий виклад призначення команди. - Синтаксис: Обов'язкові та необов'язкові аргументи. - Параметри: Прапорці та параметри, властиві саме цій команді.

version¶

Команда version виводить встановлений випуск digna. Вона не читає конфігурації й не перевіряє ліцензії, тому працює й у встановленні, де файл config.toml чи ліцензія відсутні або некоректні.

Версія випуску не пов'язана з версією схеми репозиторію, про яку звітує repo check.

Використання команди¶

digna version

Приклад виводу¶

2026.06

Керування конфігурацією¶

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 запуститися.

Використання команди¶

digna config check [OPTIONS]

Параметри¶

--configpath, -c: Шлях до файлу конфігурації або до каталогу, що містить config.toml (типово ./config.toml).
--json: Виводить звіт перевірки у форматі JSON. Має пріоритет над --quiet.
--quiet, -q: Приховує звіт і покладається виключно на код завершення.

Приклад¶

digna config check

Перевірити конкретний файл конфігурації та вивести результат у форматі JSON:

digna config check --configpath /etc/digna/config.toml --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.

Використання команди¶

digna repo check

Приклад виводу¶

Repo version 3.0.0 installed

repo install¶

Команда repo install встановлює новий репозиторій digna у схему, налаштовану в config.toml, створюючи всі потрібні послідовності, таблиці, індекси, обмеження та початкові записи.

Саму схему ця команда не створює — вона має існувати заздалегідь. Команда також відмовляється виконуватися, якщо репозиторій у цій схемі вже встановлено, і вказує на repo upgrade, якщо встановлено старішу версію.

Використання команди¶

digna repo install

Приклад виводу¶

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 застосовує міграції схеми бази даних, щоб привести наявний репозиторій до версії, якої очікує встановлений випуск. Оновлення застосовуються по одному переходу між версіями за раз уздовж фіксованого шляху оновлення, і кожен завершений перехід записується в репозиторії.

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

Використання команди¶

digna 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 записав у таблиці, що їх поточний випуск більше не використовує, залишаються без змін.

Використання команди¶

digna repo prune [OPTIONS]

Параметри¶

--dry-run: Показує, що буде видалено, нічого не видаляючи.

Перелічуються лише таблиці з осиротілими рядками. Якщо таких немає, команда повідомляє No orphaned rows found. і завершується.

Приклад¶

digna repo prune

Приклад виводу¶

"check"                                 29342
check_profile                           29342
check_prediction                        29342
check_status                            29342
column_status                              32
inspection_query                          253
---------------------------------------------
total                                  117854

✅ Removed 117854 orphaned row(s).

Щоб побачити той самий звіт, нічого не видаляючи:

digna repo prune --dry-run

Кількості рядків ідентичні; відрізняється лише завершальний рядок:

---------------------------------------------
total                                  117854

Dry run - nothing was removed.

Керування шифруванням¶

crypt gen-key¶

Команда crypt gen-key генерує новий ключ шифрування AES-GCM для використання як ключа шифрування у config.toml. Придатний до завантаження файл config.toml уже має бути наявним, хоча згенерований ключ від нього й не залежить.

Використання команди¶

digna crypt gen-key

Приклад виводу¶

Encryption key: <base64-encoded key>

crypt encrypt¶

Команда crypt encrypt шифрує рядок (наприклад, пароль до бази даних) за допомогою ключа AES-GCM, налаштованого у config.toml, і виводить шифротекст.

Використання команди¶

digna crypt encrypt <VALUE>

Аргументи¶

VALUE: Відкритий рядок, який потрібно зашифрувати (обов'язковий).

Приклад¶

digna crypt encrypt mysecretpassword

crypt decrypt¶

Команда crypt decrypt розшифровує рядок, зашифрований алгоритмом AES-GCM, за допомогою ключа, налаштованого у config.toml, і виводить відкритий текст.

Використання команди¶

digna crypt decrypt <VALUE>

Аргументи¶

VALUE: Зашифрований рядок, який потрібно розшифрувати (обов'язковий).

Приклад¶

digna crypt decrypt "encrypted_string_here"

Керування користувачами¶

user add¶

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

Використання команди¶

digna user add <EMAIL> <PASSWORD> <DISPLAY_NAME> [OPTIONS]

Аргументи¶

EMAIL: Адреса електронної пошти користувача (обов'язковий).
PASSWORD: Початковий пароль користувача (обов'язковий).
DISPLAY_NAME: Повне відображуване ім'я користувача (обов'язковий).

Параметри¶

--admin, -a: Створює користувача з правами адміністратора (суперкористувача).

Приклад¶

digna user add jdoe@example.com "SecurePass123!" "John Doe"

Створення облікового запису адміністратора:

digna user add admin@example.com "AdminPass123!" "Admin User" --admin

Приклад виводу¶

User created with ID: 42

user list¶

Команда user list виводить усіх зареєстрованих користувачів у вигляді таблиці з ідентифікатором, адресою електронної пошти, відображуваним іменем і ознакою адміністратора.

Використання команди¶

digna 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 — це перемикач, а не значення: якщо його не вказати, права адміністратора буде відкликано, тож вказуйте його щоразу, коли користувач має зберегти або отримати ці права.

Використання команди¶

digna user modify <EMAIL> <DISPLAY_NAME> [OPTIONS]

Аргументи¶

EMAIL: Адреса електронної пошти користувача, якого потрібно змінити (обов'язковий).
DISPLAY_NAME: Оновлене відображуване ім'я (обов'язковий).

Параметри¶

--admin, -a: Надає права адміністратора. Не вказуйте, щоб відкликати їх.
--valid-until, -v: Приймається задля сумісності, але наразі не застосовується. Його передавання виводить попередження й нічого не змінює.

Приклад¶

digna user modify jdoe@example.com "Johnathan Doe" --admin

Приклад виводу¶

User jdoe@example.com modified successfully

user modify-pwd¶

Команда user modify-pwd оновлює пароль наявного облікового запису користувача.

Використання команди¶

digna user modify-pwd <EMAIL> <PASSWORD>

Аргументи¶

EMAIL: Адреса електронної пошти користувача, чий пароль потрібно оновити (обов'язковий).
PASSWORD: Новий пароль (обов'язковий).

Приклад¶

digna user modify-pwd jdoe@example.com "NewSecurePass456!"

user delete¶

Команда user delete вилучає обліковий запис користувача із системи.

Використання команди¶

digna user delete <EMAIL>

Аргументи¶

EMAIL: Адреса електронної пошти користувача, якого потрібно видалити (обов'язковий).

Приклад¶

digna user delete jdoe@example.com

Керування проєктами та джерелами даних¶

project list¶

Команда project list виводить усі доступні в репозиторії проєкти з їхнім ідентифікатором, назвою та описом.

Використання команди¶

digna project list

Приклад виводу¶

ID                   NAME                           DESCRIPTION
------------------------------------------------------------------------------------------------------
7                    ProjectA                       Sales data quality
8                    ProjectB                       Finance data quality

project list-ds¶

Команда project list-ds виводить усі джерела даних, пов'язані з певним проєктом, показуючи їхній ідентифікатор, назву, вид, схему та назву таблиці.

Використання команди¶

digna project list-ds <PROJECT_NAME>

Аргументи¶

PROJECT_NAME: Назва проєкту, джерела даних якого потрібно вивести (обов'язковий). Назва має збігатися точно.

Приклад¶

digna project list-ds ProjectA

Приклад виводу¶

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, експортуються всі джерела даних проєкту.

Використання команди¶

digna project export-ds <PROJECT_NAME> [OPTIONS]

Аргументи¶

PROJECT_NAME: Назва проєкту, з якого експортуються джерела даних (обов'язковий).

Параметри¶

--table-name, -n: Назви джерел даних для експорту. Кілька назв можна вказати через пробіл.
--table-id, -i: Ідентифікатори джерел даних для експорту. Кілька ідентифікаторів можна вказати через пробіл.
--exportfile, -f: Шлях, за яким зберігаються експортовані джерела даних (типово: data_sources_export.json).

Приклад¶

Щоб експортувати всі джерела даних із ProjectA:

digna project export-ds ProjectA --exportfile my_export.json

Щоб експортувати окремі таблиці:

digna project export-ds ProjectA --table-name users orders -f users_orders_export.json

Приклад виводу¶

Successfully exported 2 data source(s) to users_orders_export.json

project import-ds¶

Команда project import-ds імпортує джерела даних із файлу експорту до цільового проєкту й повідомляє щодо кожного об'єкта, що було створено, оновлено чи пропущено.

Використання команди¶

digna project import-ds <PROJECT_NAME> <EXPORT_FILE> [OPTIONS]

Аргументи¶

PROJECT_NAME: Назва цільового проєкту, до якого виконується імпорт (обов'язковий).
EXPORT_FILE: Шлях до файлу експорту у форматі JSON (обов'язковий).

Параметри¶

--output-file, -o: Файл, до якого записується звіт про імпорт. Без нього звіт виводиться до stdout.
--output-format, -f: Формат звіту про імпорт — table, json або csv (типово: table).

Приклад¶

digna project import-ds ProjectB my_export.json

Щоб отримати звіт у машинозчитуваному вигляді:

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, і додатково подає номер кроку для кожного запланованого об'єкта.

Використання команди¶

digna project plan-import-ds <PROJECT_NAME> <EXPORT_FILE> [OPTIONS]

Аргументи¶

PROJECT_NAME: Назва цільового проєкту (обов'язковий).
EXPORT_FILE: Шлях до файлу експорту (обов'язковий).

Параметри¶

--output-file, -o: Файл, до якого записується план імпорту. Без нього план виводиться до stdout.
--output-format, -f: Формат плану імпорту — table, json або csv (типово: table).

Приклад¶

digna project plan-import-ds ProjectB my_export.json

project cleanup¶

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

Історія Timeliness і Schema Tracker не видаляється: вона фіксує те, що digna спостерігала в певний день, а не результат, отриманий на його основі, тож очищення діапазону минулих дат залишає її недоторканою.

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

Використання команди¶

digna project cleanup <PROJECT_NAME> <FROM_DATE> <TO_DATE> [OPTIONS]

Аргументи¶

PROJECT_NAME: Проєкт, який потрібно очистити (обов'язковий). Один проєкт на один виклик.
FROM_DATE: Перша дата, за яку видаляються результати, YYYY-MM-DD (обов'язковий).
TO_DATE: Остання дата, за яку видаляються результати, включно, YYYY-MM-DD (обов'язковий).

Параметри¶

--table-name, -n: Обмежує очищення цими джерелами даних. Кілька назв можна вказати через пробіл.
--table-filter: Обмежує очищення джерелами даних, назва яких містить цей підрядок.
--dry-run: Перелічує джерела даних, які буде очищено, нічого не видаляючи.
--timing: Показує, скільки часу тривало очищення.

--table-name і --table-filter поєднуються за принципом АБО — джерело даних очищується, якщо його названо або якщо збігається підрядок. Якщо жодне джерело даних не підходить, команда завершується помилкою, а не повідомляє про успіх очищення, яке нічого не зробило.

Приклад¶

digna project cleanup ProjectA 2026-01-01 2026-06-30

З обмеженням одним джерелом даних:

digna project cleanup ProjectA 2026-01-01 2026-06-30 --table-name Table1

Приклад виводу¶

Cleaning up project 'ProjectA' from 2026-01-01 to 2026-06-30:
- Table1
- Table2
- Table3

✅ Cleaned up 3 data source(s).

Щоб побачити, які джерела даних буде очищено, нічого не видаляючи:

digna project cleanup ProjectA 2026-01-01 2026-06-30 --dry-run

Кожен рядок позначено, тож пробний запуск неможливо сплутати зі справжнім:

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 є взаємовиключними.

У будь-якому режимі команда завершується ненульовим кодом завершення, якщо інспекція не була успішно завершена.

Використання команди¶

digna inspection run <PROJECT_NAME> <START_DATE> <END_DATE> [OPTIONS]

Аргументи¶

PROJECT_NAME: Назва цільового проєкту (обов'язковий). Назва має збігатися точно.
START_DATE: Початкова дата діапазону у форматі YYYY-MM-DD (обов'язковий).
END_DATE: Кінцева дата діапазону у форматі YYYY-MM-DD (обов'язковий).

Параметри¶

--table-name: Обмежує інспекцію одним джерелом даних проєкту, вказаним за назвою цього джерела. Без нього інспектуються всі джерела даних проєкту.
--async-mode: Ставить інспекцію в чергу й виводить ідентифікатор запиту замість того, щоб очікувати на нього. Не можна поєднувати з --bypass-backend.
--bypass-backend: Виконує інспекцію безпосередньо в процесі CLI замість того, щоб ставити її в чергу для серверної частини. Не можна поєднувати з --async-mode.

Приклад¶

digna inspection run ProjectA 2024-01-01 2024-01-31

Щоб надіслати асинхронну інспекцію:

digna inspection run ProjectA 2024-01-01 2024-01-31 --async-mode

Щоб проінспектувати одне джерело даних:

digna inspection run ProjectA 2024-01-01 2024-01-31 --table-name orders

Приклад виводу¶

Типовий режим:

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 request submitted successfully. Request ID: 1024

inspection status¶

Команда inspection status запитує стан і перебіг завдань запиту на інспекцію за його ідентифікатором.

Використання команди¶

digna inspection status <INSPECTION_REQUEST_ID>

Аргументи¶

INSPECTION_REQUEST_ID: Числовий ідентифікатор запиту на інспекцію (обов'язковий).

Приклад¶

digna inspection status 1024

Приклад виводу¶

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 запитує скасування запитів на інспекцію, які виконуються або очікують. Вона записує подію зупинення для кожного відповідного запиту; діє за нею серверна частина, тож переривання є проханням зупинитися, а не негайним припиненням.

Використання команди¶

digna inspection abort [INSPECTION_REQUEST_ID] [OPTIONS]

Аргументи¶

INSPECTION_REQUEST_ID: Ідентифікатор запиту на інспекцію, який потрібно перервати. Обов'язковий, якщо не вказано --killall.

Параметри¶

--killall: Перериває всі запити на інспекцію, які виконуються та очікують. Має пріоритет над ідентифікатором запиту, вказаним разом із ним.

Приклад¶

Щоб перервати конкретний запит:

digna inspection abort 1024

Щоб перервати всі активні інспекції та ті, що стоять у черзі:

digna inspection abort --killall

Приклад виводу¶

--killall повідомляє про виконане; переривання одного запиту нічого не виводить і сигналізує про успіх своїм кодом завершення.

All running and pending inspections have been aborted.

Керування ліцензіями¶

license check¶

Команда license check перевіряє файл license.toml, звіряючи його підпис із відкритим ключем, який постачається разом зі встановленням, і переконуючись, що термін його дії не минув. Вона не читає конфігурації застосунку, тож працює й до того, як налаштовано config.toml.

Використання команди¶

digna license check

Приклад виводу¶

License is valid

Недійсний підпис і ліцензія з вичерпаним терміном дії повідомляються як окремі помилки, обидві з кодом завершення 1.

Сервер і фонові служби¶

serve¶

Команда serve запускає сервер REST API digna разом із фоновим планувальником інспекцій і менеджером інспекцій. Під час запуску вона також позначає як невдалі всі інспекції, які репозиторій досі вважає такими, що виконуються, оскільки від попереднього процесу ніщо не могло вціліти.

Команда працює на передньому плані, доки її не зупинять.

Використання команди¶

digna serve [OPTIONS]

Параметри¶

--address: Мережева адреса, до якої прив'язується сервер API (типово: 127.0.0.1).
--port: Номер порту для прослуховування (типово: 8000).

Приклад¶

digna serve --address 0.0.0.0 --port 8000

Приклад виводу¶

Server running on http://0.0.0.0:8000

Керування службою Windows¶

Доступно лише у Windows. Ці команди реєструють бекенд digna у диспетчері служб Windows і керують ним; сама служба виконує serve у фоновому режимі. Кожну команду потрібно запускати з командного рядка з підвищеними правами, і кожна приймає --name, щоб можна було звернутися до служби, зареєстрованої під нестандартною назвою.

windows install¶

Команда windows install реєструє digna як службу Windows.

Адреса й порт, указані тут, записуються в реєстрацію служби, і саме до них прив'язується служба — вони не зчитуються з config.toml. Щоб змінити їх згодом, видаліть службу й установіть її знову.

Використання команди¶

digna windows install [OPTIONS]

Параметри¶

--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 --address 0.0.0.0 --port 8082

Реєстрація під другою назвою із запуском від імені облікового запису домену:

digna windows install --name digna-test --display-name "digna (test)" --account DOMAIN\svc_digna --password <password>

windows start¶

Команда windows start запускає зареєстровану службу.

Використання команди¶

digna windows start [OPTIONS]

Параметри¶

--name: Назва, під якою зареєстровано службу (типово: digna).

windows stop¶

Команда windows stop зупиняє запущену службу. Зупиняйте службу, перш ніж замінювати будь-який файл застосунку.

Використання команди¶

digna windows stop [OPTIONS]

Параметри¶

--name: Назва, під якою зареєстровано службу (типово: digna).

windows uninstall¶

Команда windows uninstall скасовує реєстрацію служби. Спершу зупиніть її.

Використання команди¶

digna windows uninstall [OPTIONS]

Параметри¶

--name: Назва, під якою зареєстровано службу (типово: digna).