digna CLI-referens 2026.06¶

2026-09-05

Den här sidan dokumenterar hela uppsättningen kommandon som finns i digna CLI-release 2026.06, inklusive användningsexempel och alternativ.

Den körbara filen heter digna.

CLI-grunder¶

Översikt & syntax¶

CLI:t i release 2026.06 använder en strukturerad, kategoribaserad kommandohierarki:

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

version och serve är fristående kommandon utan underkommando:

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

Globala alternativ¶

Följande globala alternativ gäller för samtliga kommandon:

--help, -h: Visar hjälpinformation för CLI:t eller för en specifik kommandokategori eller ett underkommando.
--stacktrace: Visar hela felkedjan vid fel i stället för enbart meddelandet på översta nivån.

--stacktrace är ett globalt alternativ i strikt mening: det måste anges före kommandokategorin, inte efter den.

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

Det finns ingen flagga --version. Använd kommandot version i stället.

Förutsättningar¶

De flesta kommandon behöver en läsbar, giltig config.toml; vissa kräver dessutom en giltig licens. Följande tabell visar vad varje kommandokategori läser in innan den gör något över huvud taget:

Kommandokategori	Behöver `config.toml`	Behöver giltig licens
`version`	nej	nej
`config check`	nej (det är just den kommandot rapporterar om)	nej
`license check`	nej	det är kontrollen
`crypt`	ja	nej
`serve`	ja	nej
`windows`	nej (tjänsten läser den när den startar)	nej
`project`	ja	nej
`user`	ja	ja
`inspection`	ja	ja
`repo`	ja	ja

Där en licens krävs kontrolleras både dess signatur och dess utgångsdatum, och kommandot avbryts innan det rör repositoryt om någon av dem underkänns.

Slutkoder¶

0: kommandot lyckades.
1: kommandot misslyckades. Felmeddelandet skrivs till stderr, med prefixet Error:.

help¶

Alternativet --help ger information om tillgängliga kommandokategorier, underkommandon och alternativ:

Visa allmän hjälp:
```
digna --help
```
Hämta hjälp för specifika kategorier och kommandon:
```
digna user --help
digna user add --help
```

Utdata omfattar: - Kommandobeskrivning: Sammanfattning av kommandots syfte. - Syntax: Obligatoriska och valfria argument. - Alternativ: Flaggor och parametrar som är specifika för kommandot.

version¶

Kommandot version skriver ut den installerade digna-releasen. Det läser ingen konfiguration och validerar ingen licens, så det fungerar även på en installation vars config.toml eller licens saknas eller är ogiltig.

Releaseversionen är oberoende av den version av repositoryschemat som rapporteras av repo check.

Kommandoanvändning¶

digna version

Exempelutdata¶

2026.06

Konfigurationshantering¶

config check¶

Kommandot config check validerar konfigurationsfilen (config.toml) och kontrollerar att alla obligatoriska sektioner och inställningar finns och är korrekt formaterade. Varje sektion valideras för sig, så att en trasig [app]-sektion inte döljer tillståndet för [repo].

De sektioner som rapporteras är:

App config ([app])
Repository config ([repo])
Base config ([base])
Logging config ([logging])
Encryption config ([encryption])
OIDC config(s) (oidc_clients) — valfri; en nyckel som saknas godkänns, medan en lista som finns men är felformad underkänns

Kommandot läser medvetet inte in applikationskonfigurationen på det sätt som de andra kommandona gör, så att det kan diagnostisera en config.toml som skulle hindra digna från att starta över huvud taget.

Kommandoanvändning¶

digna config check [OPTIONS]

Alternativ¶

--configpath, -c: Sökväg till konfigurationsfilen, eller till en katalog som innehåller config.toml (standard är ./config.toml).
--json: Skriver ut valideringsrapporten som JSON. Har företräde framför --quiet.
--quiet, -q: Undertrycker rapporten och förlitar sig enbart på slutkoden.

Exempel¶

digna config check

Validera en specifik konfigurationsfil och formatera utdata som JSON:

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

Exempelutdata¶

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

En fil som saknas eller ett TOML-syntaxfel lämnar ingenting att validera sektion för sektion och rapporteras som ett enda fel i stället för som en rapport, oavsett --quiet eller --json.

Repositoryhantering¶

repo check¶

Kommandot repo check testar databasanslutningen och verifierar repositoryts installation och version. Det misslyckas om det konfigurerade schemat inte finns, eller om det finns men inte innehåller något digna-repository.

Den version som rapporteras är versionen av repositoryschemat, som versionshanteras separat från den digna-release som skrivs ut av version.

Kommandoanvändning¶

digna repo check

Exempelutdata¶

Repo version 3.0.0 installed

repo install¶

Kommandot repo install installerar ett nytt digna-repository i det schema som konfigurerats i config.toml och skapar alla sekvenser, tabeller, index, villkor och initiala poster som krävs.

Själva schemat skapas inte av det här kommandot — det måste finnas i förväg. Kommandot vägrar också köra om ett repository redan är installerat i det schemat, och hänvisar till repo upgrade om den installerade versionen är äldre.

Kommandoanvändning¶

digna repo install

Exempelutdata¶

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¶

Kommandot repo upgrade tillämpar migreringar av databasschemat för att lyfta ett befintligt repository till den version som den installerade releasen förväntar sig. Uppgraderingar tillämpas ett versionssteg i taget längs en fast uppgraderingsväg, och varje avslutat steg registreras i repositoryt.

Om repositoryt redan har den förväntade versionen rapporterar kommandot att ingen uppgradering behövs och gör inga ändringar.

Kommandoanvändning¶

digna repo upgrade

Exempelutdata¶

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¶

Kommandot repo prune tar bort rader som har överlevt det projekt eller den datakälla de tillhörde. När ett projekt eller en datakälla tas bort försvinner själva objektet, men dess profiler, prediktioner, statusar och radantal lämnas kvar — ett medvetet val, eftersom en borttagning som också rensade de tabellerna skulle låta användaren vänta. repo prune är den städning som rensar bort dem, och det är säkert att köra när som helst: det tar bara bort rader vars projekt eller datakälla inte längre finns.

Rader som Python-backend skrivit till tabeller som den aktuella releasen inte längre använder lämnas orörda.

Kommandoanvändning¶

digna repo prune [OPTIONS]

Alternativ¶

--dry-run: Rapportera vad som skulle tas bort utan att ta bort något.

Endast tabeller med föräldralösa rader listas. Om det inte finns några rapporterar kommandot No orphaned rows found. och avslutas.

Exempel¶

digna repo prune

Exempelutdata¶

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

✅ Removed 117854 orphaned row(s).

Så här ser du samma rapport utan att ta bort något:

digna repo prune --dry-run

Radantalen är identiska; bara den avslutande raden skiljer sig:

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

Dry run - nothing was removed.

Krypteringshantering¶

crypt gen-key¶

Kommandot crypt gen-key genererar en ny AES-GCM-krypteringsnyckel, avsedd att användas som krypteringsnyckel i config.toml. En läsbar config.toml måste redan finnas, även om den genererade nyckeln inte är beroende av den.

Kommandoanvändning¶

digna crypt gen-key

Exempelutdata¶

Encryption key: <base64-encoded key>

crypt encrypt¶

Kommandot crypt encrypt krypterar en sträng (till exempel ett databaslösenord) med den AES-GCM-nyckel som konfigurerats i config.toml och skriver ut chiffertexten.

Kommandoanvändning¶

digna crypt encrypt <VALUE>

Argument¶

VALUE: Klartextsträngen som ska krypteras (obligatoriskt).

Exempel¶

digna crypt encrypt mysecretpassword

crypt decrypt¶

Kommandot crypt decrypt dekrypterar en AES-GCM-krypterad sträng med den nyckel som konfigurerats i config.toml och skriver ut klartexten.

Kommandoanvändning¶

digna crypt decrypt <VALUE>

Argument¶

VALUE: Den krypterade chiffertextsträng som ska dekrypteras (obligatoriskt).

Exempel¶

digna crypt decrypt "encrypted_string_here"

Användarhantering¶

user add¶

Kommandot user add skapar ett nytt användarkonto i digna-repositoryt. Kommandot misslyckas om en användare med den angivna e-postadressen redan finns.

Kommandoanvändning¶

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

Argument¶

EMAIL: Användarens e-postadress (obligatoriskt).
PASSWORD: Användarens initiala lösenord (obligatoriskt).
DISPLAY_NAME: Användarens fullständiga visningsnamn (obligatoriskt).

Alternativ¶

--admin, -a: Skapar användaren med administratörsbehörighet (superanvändare).

Exempel¶

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

Så här skapar du ett administratörskonto:

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

Exempelutdata¶

User created with ID: 42

user list¶

Kommandot user list listar alla registrerade användare i tabellform med ID, e-postadress, visningsnamn och administratörsflagga.

Kommandoanvändning¶

digna user list

Exempelutdata¶

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

user modify¶

Kommandot user modify uppdaterar visningsnamn och administratörsbehörighet för ett befintligt användarkonto, identifierat via e-postadress.

Både visningsnamnet och administratörsflaggan skrivs alltid. --admin är en brytare, inte ett värde: att utelämna den återkallar administratörsbehörigheten, så ange den varje gång användaren ska behålla eller få den.

Kommandoanvändning¶

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

Argument¶

EMAIL: E-postadressen för den användare som ska ändras (obligatoriskt).
DISPLAY_NAME: Det uppdaterade visningsnamnet (obligatoriskt).

Alternativ¶

--admin, -a: Ger administratörsbehörighet. Utelämna den för att återkalla den.
--valid-until, -v: Accepteras av kompatibilitetsskäl men tillämpas för närvarande inte. Om den anges skrivs en varning ut och ingenting ändras.

Exempel¶

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

Exempelutdata¶

User jdoe@example.com modified successfully

user modify-pwd¶

Kommandot user modify-pwd uppdaterar lösenordet för ett befintligt användarkonto.

Kommandoanvändning¶

digna user modify-pwd <EMAIL> <PASSWORD>

Argument¶

EMAIL: E-postadressen för den användare vars lösenord ska uppdateras (obligatoriskt).
PASSWORD: Det nya lösenordet (obligatoriskt).

Exempel¶

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

user delete¶

Kommandot user delete tar bort ett användarkonto från systemet.

Kommandoanvändning¶

digna user delete <EMAIL>

Argument¶

EMAIL: E-postadressen för den användare som ska tas bort (obligatoriskt).

Exempel¶

digna user delete jdoe@example.com

Projekt- och datakällhantering¶

project list¶

Kommandot project list listar alla tillgängliga projekt i repositoryt och visar deras ID, namn och beskrivning.

Kommandoanvändning¶

digna project list

Exempelutdata¶

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

project list-ds¶

Kommandot project list-ds listar alla datakällor som hör till ett visst projekt och visar deras ID, namn, typ, schema och tabellnamn.

Kommandoanvändning¶

digna project list-ds <PROJECT_NAME>

Argument¶

PROJECT_NAME: Namnet på det projekt vars datakällor ska listas (obligatoriskt). Namnet måste stämma exakt.

Exempel¶

digna project list-ds ProjectA

Exempelutdata¶

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

project export-ds¶

Kommandot project export-ds exporterar datakällor från ett projekt till ett JSON-dokument.

Om varken --table-name eller --table-id anges exporteras alla datakällor i projektet.

Kommandoanvändning¶

digna project export-ds <PROJECT_NAME> [OPTIONS]

Argument¶

PROJECT_NAME: Namnet på det projekt vars datakällor ska exporteras (obligatoriskt).

Alternativ¶

--table-name, -n: Namn på de datakällor som ska exporteras. Flera namn kan anges åtskilda med mellanslag.
--table-id, -i: ID:n för de datakällor som ska exporteras. Flera ID:n kan anges åtskilda med mellanslag.
--exportfile, -f: Sökväg där de exporterade datakällorna ska sparas (standard: data_sources_export.json).

Exempel¶

Så här exporterar du alla datakällor från ProjectA:

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

Så här exporterar du specifika tabeller:

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

Exempelutdata¶

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

project import-ds¶

Kommandot project import-ds importerar datakällor från en exportfil till ett målprojekt och rapporterar per objekt vad som skapades, uppdaterades eller hoppades över.

Kommandoanvändning¶

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

Argument¶

PROJECT_NAME: Namnet på det målprojekt som ska importeras till (obligatoriskt).
EXPORT_FILE: Sökväg till JSON-exportfilen (obligatoriskt).

Alternativ¶

--output-file, -o: Fil att skriva importrapporten till. Utan den går rapporten till stdout.
--output-format, -f: Format på importrapporten — table, json eller csv (standard: table).

Exempel¶

digna project import-ds ProjectB my_export.json

Så här fångar du en maskinläsbar rapport:

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

Rapporten täcker fyra objektnivåer — datakälla, datamängdsdefinition, attribut och valideringsregel — var och en med sin importåtgärd, sitt resultat, det resulterande objektets ID och eventuell ytterligare information.

project plan-import-ds¶

Kommandot project plan-import-ds förhandsvisar en import av datakällor till ett målprojekt och visar vilka objekt som skulle skapas, uppdateras eller hoppas över, utan att ändra någonting. Det tar samma exportfil och samma rapportalternativ som project import-ds, och lägger till ett stegnummer per planerat objekt.

Kommandoanvändning¶

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

Argument¶

PROJECT_NAME: Namnet på målprojektet (obligatoriskt).
EXPORT_FILE: Sökväg till exportfilen (obligatoriskt).

Alternativ¶

--output-file, -o: Fil att skriva importplanen till. Utan den går planen till stdout.
--output-format, -f: Format på importplanen — table, json eller csv (standard: table).

Exempel¶

digna project plan-import-ds ProjectB my_export.json

project cleanup¶

Kommandot project cleanup tar bort de inspektionsresultat som ett projekt har samlat på sig under ett datumintervall — profiler, prediktioner, radantal och varje status för kontroller, attribut, datamängder och datakällor. Det tar bort exakt det som en inspektion av de datumen skrev, så att intervallet kan inspekteras på nytt efteråt för att bygga upp det igen.

Historik för Timeliness och Schema Tracker tas inte bort: den registrerar vad digna observerade en viss dag snarare än ett resultat som härletts ur det, så en rensning av ett tidigare datumintervall lämnar den orörd.

Varje datakälla rensas i en egen transaktion, så en avbruten körning lämnar hela datakällor i stället för en halvt rensad.

Kommandoanvändning¶

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

Argument¶

PROJECT_NAME: Projekt som ska rensas (obligatoriskt). Ett projekt per anrop.
FROM_DATE: Första datum som resultat ska tas bort för, YYYY-MM-DD (obligatoriskt).
TO_DATE: Sista datum som resultat ska tas bort för, inklusive, YYYY-MM-DD (obligatoriskt).

Alternativ¶

--table-name, -n: Begränsa rensningen till dessa datakällor. Flera namn kan anges åtskilda med mellanslag.
--table-filter: Begränsa rensningen till datakällor vars namn innehåller denna delsträng.
--dry-run: Lista de datakällor som skulle rensas utan att ta bort något.
--timing: Visa hur lång tid rensningen tog.

--table-name och --table-filter kombineras som ett ELLER — en datakälla rensas om den anges med namn eller om delsträngen matchar. Kommandot misslyckas om ingen datakälla matchar, i stället för att rapportera framgång för en rensning som inte gjorde någonting.

Exempel¶

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

Begränsat till en datakälla:

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

Exempelutdata¶

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

✅ Cleaned up 3 data source(s).

Så här ser du vilka datakällor som skulle rensas utan att ta bort något:

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

Varje rad är markerad, så att en testkörning inte kan förväxlas med en riktig:

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.

Inspektionshantering¶

inspection run¶

Kommandot inspection run skapar en inspektionsbegäran för ett projekt och ett datumintervall och — beroende på vilka alternativ som anges — antingen väntar på den, återvänder omedelbart eller kör den i den egna processen.

De tre körlägena är:

Standard (ingen flagga): begäran köas för backend, och CLI:t pollar den varannan sekund och skriver ut uppgifternas förlopp tills inspektionen når ett sluttillstånd. Ett körande digna serve krävs, annars är det ingenting som plockar upp begäran.
--async-mode: begäran köas och dess ID skrivs ut omedelbart. Använd inspection status för att följa den.
--bypass-backend: inspektionen körs av CLI-processen själv och köas inte, så ingen körande server behövs.

--async-mode och --bypass-backend utesluter varandra.

I samtliga lägen avslutas kommandot med en slutkod som inte är noll om inspektionen inte slutfördes utan fel.

Kommandoanvändning¶

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

Argument¶

PROJECT_NAME: Namnet på målprojektet (obligatoriskt). Namnet måste stämma exakt.
START_DATE: Startdatum för datumintervallet i formatet YYYY-MM-DD (obligatoriskt).
END_DATE: Slutdatum för datumintervallet i formatet YYYY-MM-DD (obligatoriskt).

Alternativ¶

--table-name: Begränsar inspektionen till en enda datakälla i projektet, angiven med datakällans namn. Utan den inspekteras alla datakällor i projektet.
--async-mode: Köar inspektionen och skriver ut begärans ID i stället för att vänta på den. Kan inte kombineras med --bypass-backend.
--bypass-backend: Kör inspektionen direkt i CLI-processen i stället för att köa den för backend. Kan inte kombineras med --async-mode.

Exempel¶

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

Så här skickar du en asynkron inspektion:

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

Så här inspekterar du en enda datakälla:

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

Exempelutdata¶

Standardläge:

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

Asynkront läge:

Inspection request submitted successfully. Request ID: 1024

inspection status¶

Kommandot inspection status frågar efter tillstånd och uppgiftsförlopp för en inspektionsbegäran med hjälp av dess begäran-ID.

Kommandoanvändning¶

digna inspection status <INSPECTION_REQUEST_ID>

Argument¶

INSPECTION_REQUEST_ID: Det numeriska ID:t för inspektionsbegäran (obligatoriskt).

Exempel¶

digna inspection status 1024

Exempelutdata¶

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¶

Kommandot inspection abort begär att körande eller väntande inspektionsbegäranden avbryts. Det registrerar en stopphändelse för varje berörd begäran; det är backend som agerar på den, så ett avbrott är en begäran om att stoppa snarare än ett omedelbart avslut.

Kommandoanvändning¶

digna inspection abort [INSPECTION_REQUEST_ID] [OPTIONS]

Argument¶

INSPECTION_REQUEST_ID: ID:t för den inspektionsbegäran som ska avbrytas. Obligatoriskt om inte --killall anges.

Alternativ¶

--killall: Avbryter alla inspektionsbegäranden som körs eller väntar. Har företräde framför ett begäran-ID som anges tillsammans med den.

Exempel¶

Så här avbryter du en specifik begäran:

digna inspection abort 1024

Så här avbryter du alla aktiva och köade inspektioner:

digna inspection abort --killall

Exempelutdata¶

--killall rapporterar vad den gjorde; att avbryta en enskild begäran ger ingen utdata och signalerar att det gick bra via slutkoden.

All running and pending inspections have been aborted.

Licenshantering¶

license check¶

Kommandot license check validerar license.toml genom att verifiera dess signatur mot den publika nyckel som följer med installationen och kontrollera att den inte har gått ut. Det läser ingen applikationskonfiguration, så det fungerar även innan config.toml är uppsatt.

Kommandoanvändning¶

digna license check

Exempelutdata¶

License is valid

En ogiltig signatur och en utgången licens rapporteras som två skilda fel, båda med slutkod 1.

Server & bakgrundstjänster¶

serve¶

Kommandot serve startar digna REST API-servern tillsammans med schemaläggaren för inspektioner och inspektionshanteraren som körs i bakgrunden. Vid uppstart markerar det också varje inspektion som repositoryt fortfarande registrerar som körande som misslyckad, eftersom ingenting kan ha överlevt från en tidigare process.

Kommandot körs i förgrunden tills det stoppas.

Kommandoanvändning¶

digna serve [OPTIONS]

Alternativ¶

--address: Nätverksadress som API-servern ska bindas till (standard: 127.0.0.1).
--port: Portnummer att lyssna på (standard: 8000).

Exempel¶

digna serve --address 0.0.0.0 --port 8000

Exempelutdata¶

Server running on http://0.0.0.0:8000

Hantering av Windows-tjänsten¶

Endast tillgängligt på Windows. Kommandona registrerar digna-backend hos Windows tjänsthanterare och styr den; själva tjänsten kör serve i bakgrunden. Varje kommando måste köras från en upphöjd kommandotolk, och alla accepterar --name så att en tjänst som registrerats under ett annat namn än standardnamnet kan adresseras.

windows install¶

Kommandot windows install registrerar digna som en Windows-tjänst.

Adressen och porten som anges här sparas i tjänstregistreringen och är det som tjänsten binder till — de läses inte från config.toml. För att ändra dem i efterhand avinstallerar du tjänsten och installerar den igen.

Kommandoanvändning¶

digna windows install [OPTIONS]

Alternativ¶

--name: Namn som tjänsten ska registreras under (standard: digna).
--display-name: Namn som visas i services.msc (standard: digna).
--description: Beskrivning som visas i services.msc (standard: digna data quality backend).
--address: Adress som tjänsten binder sitt API till (standard: 127.0.0.1).
--port: Port som tjänsten binder sitt API till (standard: 8000).
--working-dir: Katalog som innehåller config.toml och license.toml, och som tjänsten gör till sin arbetskatalog (standard: katalogen där den körbara filen digna ligger).
--start-type: När tjänsten startar — auto med Windows, manual bara när den begärs, disabled registrerad men vägrar starta (standard: auto).
--account: Konto att köra som, t.ex. DOMAIN\user eller .\user (standard: LocalSystem).
--password: Lösenord för --account.

Exempel¶

digna windows install --address 0.0.0.0 --port 8082

Registrera under ett andra namn och kör som ett domänkonto:

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

windows start¶

Kommandot windows start startar en registrerad tjänst.

Kommandoanvändning¶

digna windows start [OPTIONS]

Alternativ¶

--name: Namn som tjänsten är registrerad under (standard: digna).

windows stop¶

Kommandot windows stop stoppar en tjänst som körs. Stoppa tjänsten innan du ersätter någon programfil.

Kommandoanvändning¶

digna windows stop [OPTIONS]

Alternativ¶

--name: Namn som tjänsten är registrerad under (standard: digna).

windows uninstall¶

Kommandot windows uninstall avregistrerar tjänsten. Stoppa den först.

Kommandoanvändning¶

digna windows uninstall [OPTIONS]

Alternativ¶

--name: Namn som tjänsten är registrerad under (standard: digna).