Referencja CLI digna 2026.06¶

2026-09-05

Ta strona dokumentuje pełny zestaw poleceń dostępnych w wydaniu 2026.06 CLI digna, wraz z przykładami użycia i opcjami.

Plik wykonywalny nazywa się digna.

Podstawy CLI¶

Przegląd i składnia¶

CLI wydania 2026.06 korzysta z uporządkowanej, opartej na kategoriach hierarchii poleceń:

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

version i serve to pojedyncze polecenia bez podpolecenia:

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

Opcje globalne¶

Poniższe opcje globalne obowiązują we wszystkich poleceniach:

--help, -h: Wyświetla informacje pomocy dotyczące CLI albo konkretnej kategorii poleceń lub podpolecenia.
--stacktrace: W razie błędu wyświetla pełny łańcuch błędów zamiast samego komunikatu najwyższego poziomu.

--stacktrace jest opcją globalną w ścisłym sensie: należy ją podać przed kategorią polecenia, a nie po niej.

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

Nie ma flagi --version. Zamiast niej użyj polecenia version.

Wymagania wstępne¶

Większość poleceń wymaga czytelnego, poprawnego pliku config.toml; niektóre dodatkowo wymagają ważnej licencji. Poniższa tabela pokazuje, co każda kategoria poleceń wczytuje, zanim cokolwiek zrobi:

Kategoria poleceń	Wymaga `config.toml`	Wymaga ważnej licencji
`version`	nie	nie
`config check`	nie (to właśnie jest to, co polecenie sprawdza)	nie
`license check`	nie	to jest ta kontrola
`crypt`	tak	nie
`serve`	tak	nie
`windows`	nie (usługa odczytuje go przy uruchomieniu)	nie
`project`	tak	nie
`user`	tak	tak
`inspection`	tak	tak
`repo`	tak	tak

Tam, gdzie licencja jest wymagana, sprawdzane są zarówno jej podpis, jak i data wygaśnięcia, a polecenie przerywa działanie, zanim dotknie repozytorium, jeśli którakolwiek z tych kontroli się nie powiedzie.

Kody wyjścia¶

0: polecenie zakończyło się powodzeniem.
1: polecenie się nie powiodło. Komunikat o błędzie jest zapisywany na stderr, poprzedzony prefiksem Error:.

help¶

Opcja --help udostępnia informacje o dostępnych kategoriach poleceń, podpoleceniach i opcjach:

Wyświetlanie pomocy ogólnej:
```
digna --help
```
Uzyskiwanie pomocy dla konkretnych kategorii i poleceń:
```
digna user --help
digna user add --help
```

Wyjście zawiera: - Opis polecenia: Podsumowanie przeznaczenia polecenia. - Składnię: Argumenty wymagane i opcjonalne. - Opcje: Flagi i parametry właściwe dla danego polecenia.

version¶

Polecenie version wypisuje zainstalowane wydanie digna. Nie wczytuje żadnej konfiguracji ani nie weryfikuje licencji, więc działa również w instalacji, w której config.toml lub licencja są nieobecne albo nieprawidłowe.

Wersja wydania jest niezależna od wersji schematu repozytorium raportowanej przez repo check.

Użycie polecenia¶

digna version

Przykładowe wyjście¶

2026.06

Zarządzanie konfiguracją¶

config check¶

Polecenie config check weryfikuje plik konfiguracyjny (config.toml), sprawdzając, czy wszystkie obowiązkowe sekcje i ustawienia są obecne i poprawnie sformatowane. Każda sekcja jest weryfikowana osobno, dzięki czemu uszkodzona sekcja [app] nie przesłania stanu sekcji [repo].

Raportowane są następujące sekcje:

App config ([app])
Repository config ([repo])
Base config ([base])
Logging config ([logging])
Encryption config ([encryption])
OIDC config(s) (oidc_clients) — opcjonalna; brak klucza przechodzi kontrolę, obecna, lecz niepoprawnie zbudowana lista jej nie przechodzi

Polecenie celowo nie wczytuje konfiguracji aplikacji w taki sposób, jak robią to pozostałe polecenia, aby móc zdiagnozować plik config.toml, który w ogóle uniemożliwiłby uruchomienie digna.

Użycie polecenia¶

digna config check [OPTIONS]

Opcje¶

--configpath, -c: Ścieżka do pliku konfiguracyjnego lub do katalogu zawierającego config.toml (domyślnie ./config.toml).
--json: Wypisuje raport weryfikacji w formacie JSON. Ma pierwszeństwo przed --quiet.
--quiet, -q: Pomija raport i opiera się wyłącznie na kodzie wyjścia.

Przykład¶

digna config check

Weryfikacja konkretnego pliku konfiguracyjnego z wyjściem w formacie JSON:

digna config check --configpath /etc/digna/config.toml --json

Przykładowe wyjście¶

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

Brakujący plik lub błąd składni TOML nie pozostawia niczego, co można by weryfikować sekcja po sekcji, i jest zgłaszany jako pojedynczy błąd zamiast raportu, niezależnie od --quiet czy --json.

Zarządzanie repozytorium¶

repo check¶

Polecenie repo check testuje połączenie z bazą danych oraz weryfikuje instalację i wersję repozytorium. Kończy się niepowodzeniem, jeśli skonfigurowany schemat nie istnieje albo istnieje, lecz nie zawiera repozytorium digna.

Raportowana wersja to wersja schematu repozytorium, która jest wersjonowana niezależnie od wydania digna wypisywanego przez version.

Użycie polecenia¶

digna repo check

Przykładowe wyjście¶

Repo version 3.0.0 installed

repo install¶

Polecenie repo install instaluje nowe repozytorium digna w schemacie skonfigurowanym w config.toml, tworząc wszystkie wymagane sekwencje, tabele, indeksy, ograniczenia i rekordy początkowe.

Sam schemat nie jest tworzony przez to polecenie — musi istnieć wcześniej. Polecenie odmawia też działania, jeśli w tym schemacie zainstalowano już repozytorium, i wskazuje na repo upgrade, jeśli zainstalowana wersja jest starsza.

Użycie polecenia¶

digna repo install

Przykładowe wyjście¶

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¶

Polecenie repo upgrade stosuje migracje schematu bazy danych, aby doprowadzić istniejące repozytorium do wersji oczekiwanej przez zainstalowane wydanie. Aktualizacje są stosowane po jednym skoku wersji naraz wzdłuż ustalonej ścieżki aktualizacji, a każdy ukończony skok jest zapisywany w repozytorium.

Jeśli repozytorium jest już w oczekiwanej wersji, polecenie zgłasza, że aktualizacja nie jest potrzebna, i nie wprowadza żadnych zmian.

Użycie polecenia¶

digna repo upgrade

Przykładowe wyjście¶

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¶

Polecenie repo prune usuwa wiersze, które przetrwały projekt lub źródło danych, do którego należały. Usunięcie projektu lub źródła danych usuwa sam obiekt, ale pozostawia jego profile, predykcje, statusy i liczby wierszy — to świadomy kompromis, ponieważ usuwanie, które czyściłoby również te tabele, kazałoby użytkownikowi czekać. repo prune to przebieg porządkowy, który je usuwa, i można go bezpiecznie uruchomić w dowolnym momencie: usuwa wyłącznie wiersze, których projekt lub źródło danych już nie istnieje.

Wiersze zapisane przez backend w Pythonie w tabelach, których bieżące wydanie już nie używa, pozostają nienaruszone.

Użycie polecenia¶

digna repo prune [OPTIONS]

Opcje¶

--dry-run: Pokazuje, co zostałoby usunięte, niczego nie usuwając.

Wyświetlane są tylko tabele z osieroconymi wierszami. Jeśli takich nie ma, polecenie zgłasza No orphaned rows found. i kończy działanie.

Przykład¶

digna repo prune

Przykładowe wyjście¶

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

✅ Removed 117854 orphaned row(s).

Aby zobaczyć ten sam raport bez usuwania czegokolwiek:

digna repo prune --dry-run

Liczby wierszy są identyczne; różni się tylko ostatni wiersz:

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

Dry run - nothing was removed.

Zarządzanie szyfrowaniem¶

crypt gen-key¶

Polecenie crypt gen-key generuje nowy klucz szyfrujący AES-GCM, przeznaczony do użycia jako klucz szyfrowania w config.toml. Musi już istnieć możliwy do wczytania plik config.toml, mimo że wygenerowany klucz od niego nie zależy.

Użycie polecenia¶

digna crypt gen-key

Przykładowe wyjście¶

Encryption key: <base64-encoded key>

crypt encrypt¶

Polecenie crypt encrypt szyfruje ciąg znaków (na przykład hasło do bazy danych) przy użyciu klucza AES-GCM skonfigurowanego w config.toml i wypisuje szyfrogram.

Użycie polecenia¶

digna crypt encrypt <VALUE>

Argumenty¶

VALUE: Jawny ciąg znaków do zaszyfrowania (wymagany).

Przykład¶

digna crypt encrypt mysecretpassword

crypt decrypt¶

Polecenie crypt decrypt odszyfrowuje ciąg znaków zaszyfrowany algorytmem AES-GCM przy użyciu klucza skonfigurowanego w config.toml i wypisuje tekst jawny.

Użycie polecenia¶

digna crypt decrypt <VALUE>

Argumenty¶

VALUE: Zaszyfrowany ciąg znaków do odszyfrowania (wymagany).

Przykład¶

digna crypt decrypt "encrypted_string_here"

Zarządzanie użytkownikami¶

user add¶

Polecenie user add tworzy nowe konto użytkownika w repozytorium digna. Polecenie kończy się niepowodzeniem, jeśli użytkownik o podanym adresie e-mail już istnieje.

Użycie polecenia¶

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

Argumenty¶

EMAIL: Adres e-mail użytkownika (wymagany).
PASSWORD: Początkowe hasło użytkownika (wymagane).
DISPLAY_NAME: Pełna nazwa wyświetlana użytkownika (wymagana).

Opcje¶

--admin, -a: Tworzy użytkownika z uprawnieniami administratora (superużytkownika).

Przykład¶

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

Aby utworzyć konto administratora:

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

Przykładowe wyjście¶

User created with ID: 42

user list¶

Polecenie user list wyświetla wszystkich zarejestrowanych użytkowników w formie tabeli, z identyfikatorem, adresem e-mail, nazwą wyświetlaną i flagą administratora.

Użycie polecenia¶

digna user list

Przykładowe wyjście¶

ID                   EMAIL                          DISPLAY NAME                   ADMIN
-----------------------------------------------------------------------------------------------
42                   jdoe@example.com               John Doe                       false
43                   admin@example.com              Admin User                     true

user modify¶

Polecenie user modify aktualizuje nazwę wyświetlaną i uprawnienia administratora istniejącego konta użytkownika, wskazanego adresem e-mail.

Zarówno nazwa wyświetlana, jak i flaga administratora są zapisywane za każdym razem. --admin jest przełącznikiem, a nie wartością: jej pominięcie odbiera uprawnienia administratora, dlatego podawaj ją zawsze, gdy użytkownik ma je zachować lub uzyskać.

Użycie polecenia¶

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

Argumenty¶

EMAIL: Adres e-mail modyfikowanego użytkownika (wymagany).
DISPLAY_NAME: Zaktualizowana nazwa wyświetlana (wymagana).

Opcje¶

--admin, -a: Nadaje uprawnienia administratora. Pomiń, aby je odebrać.
--valid-until, -v: Akceptowana ze względu na zgodność, ale obecnie nieuwzględniana. Jej podanie powoduje wypisanie ostrzeżenia i niczego nie zmienia.

Przykład¶

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

Przykładowe wyjście¶

User jdoe@example.com modified successfully

user modify-pwd¶

Polecenie user modify-pwd aktualizuje hasło istniejącego konta użytkownika.

Użycie polecenia¶

digna user modify-pwd <EMAIL> <PASSWORD>

Argumenty¶

EMAIL: Adres e-mail użytkownika, którego hasło ma zostać zaktualizowane (wymagany).
PASSWORD: Nowe hasło (wymagane).

Przykład¶

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

user delete¶

Polecenie user delete usuwa konto użytkownika z systemu.

Użycie polecenia¶

digna user delete <EMAIL>

Argumenty¶

EMAIL: Adres e-mail użytkownika do usunięcia (wymagany).

Przykład¶

digna user delete jdoe@example.com

Zarządzanie projektami i źródłami danych¶

project list¶

Polecenie project list wyświetla wszystkie dostępne projekty w repozytorium wraz z ich identyfikatorem, nazwą i opisem.

Użycie polecenia¶

digna project list

Przykładowe wyjście¶

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

project list-ds¶

Polecenie project list-ds wyświetla wszystkie źródła danych powiązane z danym projektem, pokazując ich identyfikator, nazwę, rodzaj, schemat i nazwę tabeli.

Użycie polecenia¶

digna project list-ds <PROJECT_NAME>

Argumenty¶

PROJECT_NAME: Nazwa projektu, którego źródła danych mają zostać wyświetlone (wymagana). Nazwa musi być dokładnie zgodna.

Przykład¶

digna project list-ds ProjectA

Przykładowe wyjście¶

ID                   NAME                           KIND            SCHEMA               TABLE
-------------------------------------------------------------------------------------------------------------
101                  orders                         Table           sales                orders
102                  customers                      Table           sales                customers

project export-ds¶

Polecenie project export-ds eksportuje źródła danych z projektu do dokumentu JSON.

Jeśli nie podano ani --table-name, ani --table-id, eksportowane są wszystkie źródła danych projektu.

Użycie polecenia¶

digna project export-ds <PROJECT_NAME> [OPTIONS]

Argumenty¶

PROJECT_NAME: Nazwa projektu, z którego mają zostać wyeksportowane źródła danych (wymagana).

Opcje¶

--table-name, -n: Nazwy źródeł danych do wyeksportowania. Można podać wiele nazw oddzielonych spacjami.
--table-id, -i: Identyfikatory źródeł danych do wyeksportowania. Można podać wiele identyfikatorów oddzielonych spacjami.
--exportfile, -f: Ścieżka, pod którą zostaną zapisane wyeksportowane źródła danych (domyślnie: data_sources_export.json).

Przykład¶

Aby wyeksportować wszystkie źródła danych z ProjectA:

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

Aby wyeksportować wybrane tabele:

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

Przykładowe wyjście¶

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

project import-ds¶

Polecenie project import-ds importuje źródła danych z pliku eksportu do projektu docelowego i raportuje dla każdego obiektu, co zostało utworzone, zaktualizowane lub pominięte.

Użycie polecenia¶

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

Argumenty¶

PROJECT_NAME: Nazwa projektu docelowego, do którego następuje import (wymagana).
EXPORT_FILE: Ścieżka do pliku eksportu JSON (wymagana).

Opcje¶

--output-file, -o: Plik, do którego zostanie zapisany raport importu. Bez tej opcji raport trafia na stdout.
--output-format, -f: Format raportu importu — table, json lub csv (domyślnie: table).

Przykład¶

digna project import-ds ProjectB my_export.json

Aby uzyskać raport w formacie nadającym się do przetwarzania maszynowego:

digna project import-ds ProjectB my_export.json --output-format json --output-file import_report.json

Raport obejmuje cztery poziomy obiektów — źródło danych, definicję zbioru danych, atrybut i regułę walidacji — każdy wraz z akcją importu, wynikiem, identyfikatorem powstałego obiektu oraz ewentualnymi dodatkowymi informacjami.

project plan-import-ds¶

Polecenie project plan-import-ds pokazuje podgląd importu źródeł danych do projektu docelowego, wskazując, które obiekty zostałyby utworzone, zaktualizowane lub pominięte, bez wprowadzania jakichkolwiek zmian. Przyjmuje ten sam plik eksportu i te same opcje raportowania co project import-ds, a dodatkowo podaje numer kroku dla każdego zaplanowanego obiektu.

Użycie polecenia¶

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

Argumenty¶

PROJECT_NAME: Nazwa projektu docelowego (wymagana).
EXPORT_FILE: Ścieżka do pliku eksportu (wymagana).

Opcje¶

--output-file, -o: Plik, do którego zostanie zapisany plan importu. Bez tej opcji plan trafia na stdout.
--output-format, -f: Format planu importu — table, json lub csv (domyślnie: table).

Przykład¶

digna project plan-import-ds ProjectB my_export.json

project cleanup¶

Polecenie project cleanup usuwa wyniki inspekcji, które projekt zgromadził w danym zakresie dat — profile, predykcje, liczby wierszy oraz wszystkie statusy kontroli, atrybutów, zbiorów danych i źródeł danych. Usuwa dokładnie to, co zapisała inspekcja z tych dat, więc po wszystkim można ponownie przeprowadzić inspekcję tego zakresu, aby odbudować wyniki.

Historia Timeliness i Schema Tracker nie jest usuwana: rejestruje ona to, co digna zaobserwowała danego dnia, a nie wynik z tego wyprowadzony, więc czyszczenie minionego zakresu dat pozostawia ją nienaruszoną.

Każde źródło danych jest czyszczone we własnej transakcji, więc przerwany przebieg pozostawia całe źródła danych, a nie źródło wyczyszczone tylko w połowie.

Użycie polecenia¶

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

Argumenty¶

PROJECT_NAME: Projekt do wyczyszczenia (wymagany). Jeden projekt na wywołanie.
FROM_DATE: Pierwsza data, dla której mają zostać usunięte wyniki, YYYY-MM-DD (wymagana).
TO_DATE: Ostatnia data, dla której mają zostać usunięte wyniki, włącznie, YYYY-MM-DD (wymagana).

Opcje¶

--table-name, -n: Ogranicza czyszczenie do tych źródeł danych. Można podać wiele nazw oddzielonych spacjami.
--table-filter: Ogranicza czyszczenie do źródeł danych, których nazwa zawiera ten podciąg.
--dry-run: Wyświetla źródła danych, które zostałyby wyczyszczone, niczego nie usuwając.
--timing: Pokazuje, ile trwało czyszczenie.

--table-name i --table-filter łączą się jak LUB — źródło danych jest czyszczone, jeśli zostało wymienione z nazwy lub jeśli pasuje podciąg. Polecenie kończy się błędem, jeśli żadne źródło danych nie pasuje, zamiast zgłaszać powodzenie czyszczenia, które nic nie zrobiło.

Przykład¶

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

Z ograniczeniem do jednego źródła danych:

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

Przykładowe wyjście¶

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

✅ Cleaned up 3 data source(s).

Aby zobaczyć, które źródła danych zostałyby wyczyszczone, bez usuwania czegokolwiek:

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

Każdy wiersz jest oznaczony, więc przebiegu próbnego nie da się pomylić z rzeczywistym:

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.

Zarządzanie inspekcjami¶

inspection run¶

Polecenie inspection run tworzy żądanie inspekcji dla projektu i zakresu dat, a następnie — zależnie od podanych opcji — albo na nie czeka, albo natychmiast kończy działanie, albo wykonuje je we własnym procesie.

Trzy tryby wykonania to:

Domyślny (bez flagi): żądanie trafia do kolejki backendu, a CLI odpytuje je co dwie sekundy, wypisując postęp zadań, dopóki inspekcja nie osiągnie stanu końcowego. Wymagany jest działający digna serve, w przeciwnym razie nic nie odbierze żądania.
--async-mode: żądanie trafia do kolejki, a jego identyfikator jest wypisywany natychmiast. Do jego śledzenia użyj inspection status.
--bypass-backend: inspekcja jest wykonywana przez sam proces CLI i nie trafia do kolejki, więc działający serwer nie jest potrzebny.

--async-mode i --bypass-backend wzajemnie się wykluczają.

W każdym trybie polecenie kończy się niezerowym kodem wyjścia, jeśli inspekcja nie zakończyła się powodzeniem.

Użycie polecenia¶

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

Argumenty¶

PROJECT_NAME: Nazwa projektu docelowego (wymagana). Nazwa musi być dokładnie zgodna.
START_DATE: Data początkowa zakresu dat w formacie YYYY-MM-DD (wymagana).
END_DATE: Data końcowa zakresu dat w formacie YYYY-MM-DD (wymagana).

Opcje¶

--table-name: Ogranicza inspekcję do jednego źródła danych projektu, wskazanego nazwą tego źródła. Bez tej opcji inspekcji podlegają wszystkie źródła danych projektu.
--async-mode: Umieszcza inspekcję w kolejce i wypisuje identyfikator żądania zamiast na nie czekać. Nie można łączyć z --bypass-backend.
--bypass-backend: Uruchamia inspekcję bezpośrednio w procesie CLI zamiast umieszczać ją w kolejce backendu. Nie można łączyć z --async-mode.

Przykład¶

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

Aby zlecić inspekcję asynchroniczną:

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

Aby przeprowadzić inspekcję jednego źródła danych:

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

Przykładowe wyjście¶

Tryb domyślny:

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

Tryb asynchroniczny:

Inspection request submitted successfully. Request ID: 1024

inspection status¶

Polecenie inspection status odpytuje o stan i postęp zadań żądania inspekcji na podstawie jego identyfikatora.

Użycie polecenia¶

digna inspection status <INSPECTION_REQUEST_ID>

Argumenty¶

INSPECTION_REQUEST_ID: Liczbowy identyfikator żądania inspekcji (wymagany).

Przykład¶

digna inspection status 1024

Przykładowe wyjście¶

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¶

Polecenie inspection abort zgłasza żądanie anulowania trwających lub oczekujących żądań inspekcji. Zapisuje zdarzenie zatrzymania dla każdego objętego nim żądania; działa na nie backend, więc przerwanie jest prośbą o zatrzymanie, a nie natychmiastowym zabiciem procesu.

Użycie polecenia¶

digna inspection abort [INSPECTION_REQUEST_ID] [OPTIONS]

Argumenty¶

INSPECTION_REQUEST_ID: Identyfikator żądania inspekcji do przerwania. Wymagany, chyba że podano --killall.

Opcje¶

--killall: Przerywa wszystkie aktualnie trwające i oczekujące żądania inspekcji. Ma pierwszeństwo przed identyfikatorem żądania podanym obok niej.

Przykład¶

Aby przerwać konkretne żądanie:

digna inspection abort 1024

Aby przerwać wszystkie aktywne i oczekujące w kolejce inspekcje:

digna inspection abort --killall

Przykładowe wyjście¶

--killall raportuje, co zrobiła; przerwanie pojedynczego żądania nie daje żadnego wyjścia i sygnalizuje powodzenie kodem wyjścia.

All running and pending inspections have been aborted.

Zarządzanie licencjami¶

license check¶

Polecenie license check weryfikuje plik license.toml, sprawdzając jego podpis przy użyciu klucza publicznego dostarczanego wraz z instalacją oraz kontrolując, czy licencja nie wygasła. Nie wczytuje żadnej konfiguracji aplikacji, więc działa również zanim config.toml zostanie skonfigurowany.

Użycie polecenia¶

digna license check

Przykładowe wyjście¶

License is valid

Nieprawidłowy podpis i wygasła licencja są zgłaszane jako odrębne błędy, oba z kodem wyjścia 1.

Serwer i usługi działające w tle¶

serve¶

Polecenie serve uruchamia serwer REST API digna wraz z działającymi w tle harmonogramem inspekcji i menedżerem inspekcji. Podczas uruchamiania oznacza także jako nieudaną każdą inspekcję, którą repozytorium wciąż zapisuje jako trwającą, ponieważ nic nie mogło przetrwać z wcześniejszego procesu.

Polecenie działa na pierwszym planie, dopóki nie zostanie zatrzymane.

Użycie polecenia¶

digna serve [OPTIONS]

Opcje¶

--address: Adres sieciowy, na którym nasłuchuje serwer API (domyślnie: 127.0.0.1).
--port: Numer portu, na którym prowadzone jest nasłuchiwanie (domyślnie: 8000).

Przykład¶

digna serve --address 0.0.0.0 --port 8000

Przykładowe wyjście¶

Server running on http://0.0.0.0:8000

Zarządzanie usługą Windows¶

Dostępne tylko w systemie Windows. Polecenia rejestrują backend digna w menedżerze usług Windows i sterują nim; sama usługa uruchamia serve w tle. Każde polecenie należy uruchamiać z wiersza polecenia z podwyższonymi uprawnieniami, a każde przyjmuje --name, aby można było wskazać usługę zarejestrowaną pod nazwą inną niż domyślna.

windows install¶

Polecenie windows install rejestruje digna jako usługę Windows.

Podane tu adres i port są zapisywane w rejestracji usługi i to na nich usługa nasłuchuje — nie są odczytywane z config.toml. Aby je później zmienić, odinstaluj usługę i zainstaluj ją ponownie.

Użycie polecenia¶

digna windows install [OPTIONS]

Opcje¶

--name: Nazwa, pod którą usługa ma zostać zarejestrowana (domyślnie: digna).
--display-name: Nazwa wyświetlana w services.msc (domyślnie: digna).
--description: Opis wyświetlany w services.msc (domyślnie: digna data quality backend).
--address: Adres, na którym usługa udostępnia swoje API (domyślnie: 127.0.0.1).
--port: Port, na którym usługa udostępnia swoje API (domyślnie: 8000).
--working-dir: Katalog zawierający config.toml i license.toml, który usługa ustawia jako swój katalog roboczy (domyślnie: katalog pliku wykonywalnego digna).
--start-type: Kiedy usługa się uruchamia — auto razem z systemem Windows, manual tylko na żądanie, disabled zarejestrowana, ale odmawia uruchomienia (domyślnie: auto).
--account: Konto, na którym usługa ma działać, np. DOMAIN\user lub .\user (domyślnie: LocalSystem).
--password: Hasło konta --account.

Przykład¶

digna windows install --address 0.0.0.0 --port 8082

Rejestracja pod drugą nazwą, z uruchamianiem na koncie domenowym:

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

windows start¶

Polecenie windows start uruchamia zarejestrowaną usługę.

Użycie polecenia¶

digna windows start [OPTIONS]

Opcje¶

--name: Nazwa, pod którą usługa jest zarejestrowana (domyślnie: digna).

windows stop¶

Polecenie windows stop zatrzymuje działającą usługę. Zatrzymaj usługę przed zastąpieniem któregokolwiek pliku aplikacji.

Użycie polecenia¶

digna windows stop [OPTIONS]

Opcje¶

--name: Nazwa, pod którą usługa jest zarejestrowana (domyślnie: digna).

windows uninstall¶

Polecenie windows uninstall wyrejestrowuje usługę. Najpierw ją zatrzymaj.

Użycie polecenia¶

digna windows uninstall [OPTIONS]

Opcje¶

--name: Nazwa, pod którą usługa jest zarejestrowana (domyślnie: digna).