AI agent CI/CD s DOCKUP_TOKEN

AI agent CI/CD funguje spoľahlivo iba vtedy, keď autentifikácia a nasadenie prebehnú správne bez človeka pri termináli. Prihlásenie v prehliadači, kopírovanie jednorazových kódov a stavové správy vo forme bežného textu nie sú kompatibilné s unattended runnerom. Dockup podporuje neinteraktívny postup prostredníctvom DOCKUP_TOKEN, štruktúrovaného JSON a príkazov na nasadenie, ktoré vracajú skutočný nenulový exit code pri zlyhaní.

Táto príručka vytvára kontrakt pipeline, ktorý môže používať Claude Code, Codex, shell skript aj štandardná CI úloha. Platia rovnaké pravidlá: token injektujte až za behu, overte identitu, vyhľadajte alebo presne zadajte cieľ, počkajte na konečný výsledok a pri zlyhaní zachovajte diagnostické údaje.

Prečo AI agent CI/CD potrebuje neinteraktívnu autentifikáciu?

Interaktívne dockup login otvorí autentifikačnú stránku a čaká na token. To je vhodné na pracovnej stanici vývojára, no kontajnerizovaný runner nemusí mať prehliadač, trvalý domovský adresár ani človeka, ktorý by mohol niečo vložiť.

DOCKUP_TOKEN rieši túto hranicu:

export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Premenná prostredia má prednosť pred ~/.dockup/config.json. whoami uvádza tokenSource, takže pipeline môže dokázať, že používa zamýšľané injektované prihlasovacie údaje, a nie starý konfiguračný súbor, ktorý zostal na self-hosted runneri.

V CI nespúšťajte dockup login -t "$DOCKUP_TOKEN", pokiaľ nemáte konkrétny dôvod na uloženie konfiguračného súboru. Priame zadanie premennej prostredia ponechá prihlasovací údaj v rozsahu procesu a zabráni jeho zápisu do domovského adresára runnera.

Pipeline nesmie token nikdy vypísať. Vypnite shell tracing pri príkazoch obsahujúcich tajomstvá, vyhnite sa výpisu celého prostredia a použite funkciu CI platformy na maskovanie tajomstiev.

Ako ukladať a obmedziť rozsah DOCKUP_TOKEN?

Token uložte ako šifrované tajomstvo repozitára, prostredia alebo organizácie. V produkcii uprednostnite tajomstvo na úrovni prostredia, pretože ho možno skombinovať s obmedzeniami vetiev a manuálnym schvaľovaním, ktoré poskytuje CI platforma.

Bezpečnostná politika tokenu by mala zodpovedať päť otázok:

Otázka	Odporúčaná odpoveď
Kde je token uložený?	Šifrované úložisko tajomstiev CI
Kedy je sprístupnený?	Iba v jobe na nasadenie
Ktoré vetvy ho môžu používať?	Chránené produkčné vetvy
Kto môže meniť workflow?	Schválení maintainers
Ako sa používanie kontroluje?	Audit log Dockup a história CI jobov

Dockup podporuje aj API kľúče s oprávneniami. Pred vytvorením úzko špecializovaného kľúča si vypíšte dostupné názvy oprávnení:

dockup keys permissions --json

Vyberte iba presné názvy oprávnení vrátené platformou a potom vytvorte kľúč prostredníctvom workflow pre API kľúče s oprávneniami. Vygenerovaný kľúč pri vytváraní bezpečne zachyťte a okamžite uložte. Neuvádzajte ho v issue, pull requestoch ani v prepise konverzácie agenta; deployment job by nemal zdediť široké oprávnenia na správu účtu len preto, že ich už má vývojársky token.

Článok Bezpečnostné pravidlá pre AI agentov v produkcii ponúka širší model úrovní oprávnení.

Ako vytvoriť deployment pipeline, ktorá čaká na skutočný výsledok?

Nainštalujte CLI v jobe, overte identitu a potom nasaďte pomocou --wait:

name: production-deploy

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      DOCKUP_TOKEN: ${{ secrets.DOCKUP_TOKEN }}
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - name: Install Dockup CLI
        run: npm install -g dockup-cli

      - name: Verify Dockup identity
        run: dockup whoami --json

      - name: Deploy and wait
        run: dockup deploy production/api --wait --json

Dôležitý nie je dodávateľ CI. Dôležitý je kontrakt príkazu. dockup deploy ... --wait --json skončí s kódom 0 iba vtedy, keď nasadenie dosiahne úspešný stav. Predvolený timeout je 900 sekúnd. Neúspešný build vráti nenulový exit code s kódom deploy_failed; nekonečný proces, ktorý pri vypršaní timeoutu nedosiahol konečný stav, vráti deploy_timeout.

Keďže proces skončí s nenulovým kódom, runner označí krok aj job ako neúspešný. Nie je potrebné analyzovať logy.

Pri prepojenom repozitári, ktorý má odoslať aktuálnu vetvu a následne ju nasadiť, dockup push --json predvolene čaká. V CI jobe, ktorý už dostal udalosť Git push, je často prehľadnejšie použiť explicitné dockup deploy <target>, pretože sa tým zabráni odoslaniu zmien z runnera.

Ako má pipeline zachytávať logy a chybové kódy?

Výsledok nasadenia vo formáte JSON zachovajte ako artifact alebo výstup jobu, no nedovoľte, aby presmerovanie skrylo exit status. Shell pattern môže zachytiť oboje:

set +e
dockup deploy production/api --wait --json > deploy-result.json
status=$?
set -e

if [ "$status" -ne 0 ]; then
  dockup logs production/api --build --json > build-logs.json || true
  cat deploy-result.json
  exit "$status"
fi

dockup status production/api --json

Pipeline skončí s pôvodným statusom nasadenia. Build logy sa zhromaždia iba po zlyhaní. Runtime logy zhromažďujte vtedy, keď sa image zostavil, no aplikácia neskôr spadne:

dockup logs production/api --json

Na sledovanie priebehu buildu v reálnom čase režim follow vypisuje NDJSON:

dockup logs production/api --build -f --json

Stream sa ukončí spolu s nasadením a zlyhanie zostane reprezentované nenulovým výsledkom procesu. Podrobnú diagnostickú postupnosť nájdete v článku Ladenie build a runtime logov.

Pipeline by mala vetviť podľa kódov, nie podľa fragmentov správ:

Kód	Reakcia pipeline
not_logged_in	Okamžite zlyhať; injektovanie tajomstva je nefunkčné
no_target	Zlyhať; konfigurácia cieľa je neplatná
deploy_trigger_failed	Zlyhať ešte pred čakaním; skontrolovať vrátenú chybu
deploy_failed	Nahrať build logy a zlyhať
deploy_timeout	Označiť ako neisté; pred opakovaním skontrolovať status
needs_confirm	Zastaviť; deštruktívny krok nemá schválenie

Ako sa môže agent zapojiť bez oslabenia bezpečnosti CI?

Agent môže pripraviť kód, upraviť skontrolovaný workflow, interpretovať JSON a zhrnúť neúspešný build. Počas každého programátorského sedenia nepotrebuje neobmedzený prístup k produkčnému tokenu.

Oddeľte jednotlivé roly:

1. Vývojový agent: upravuje kód a lokálne spúšťa testy.
2. Proces kontroly: overuje zmeny v konfigurácii nasadenia.
3. CI runner: dostane DOCKUP_TOKEN až po schválenom spúšťacom podnete.
4. Dockup: vykoná nasadenie a zaznamená auditné udalosti.
5. Agent alebo operátor: interpretuje výsledok a navrhne obnovu.

Toto usporiadanie zabráni tomu, aby prompt injection v nesúvisiacej úlohe získal produkčné prihlasovacie údaje. Agent môže pipeline stále pochopiť, pretože príkazy a očakávaný JSON sú uložené v repozitári, zatiaľ čo hodnota tajomstva zostáva mimo neho.

Pri nasadeniach spúšťaných priamo agentom injektujte token do konkrétneho procesu Claude Code alebo Codex a nainštalujte pribalený skill:

npm install -g dockup-cli
dockup skill install
dockup whoami --json

Skill učí oboch agentov používať neinteraktívnu autentifikáciu, JSON, presné vyhľadávanie cieľa, čakanie na konečný stav a schvaľovacie brány.

Vďaka čomu je AI agent CI/CD opakovateľné a auditovateľné?

Opakovateľnosť začína explicitne určeným cieľom. production/api uložte ako chránenú premennú pipeline alebo ako skontrolovanú konštantu, nie ako názov, ktorý agent odvodí za behu. Ešte pred prvým zápisom overte účet.

Idempotencia si vyžaduje odlišný prístup podľa typu operácie:

• Opakované čítanie identity, statusu, logov a histórie je bezpečné.
• Vytvorenie služby musí začať vyhľadaním cieľa, aby opakovanie nevytvorilo duplikát.
• Opätovné nasadenie vytvorí ďalšiu produkčnú udalosť a malo by sa zaznamenať.
• Zmeny prostredia sú mutácie a vyžadujú nové nasadenie.
• Deštrukcia a prerezávanie nesmú byť automatickými cieľmi opakovania.

Po nasadení zhromaždite dôkazy z platformy:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup audit --writes --json

Uptime sa meria každú minútu a zahŕňa priemerný čas odozvy aj p95. Auditný výstup prepája mutáciu vykonanú CI s neskoršou kontrolou. Spotreba CPU, RAM a disku sa tiež meria každú minútu voči zostatku účtu; odporúčaný Pro plan stojí 20 $ mesačne s kreditom 20 $ na využitie.

Úplný záznam pipeline obsahuje Git commit, cieľ Dockup, ID nasadenia, čas začiatku a dokončenia, exit code, konečný status a odkazy na build artifacts. Vďaka tomu je vydanie AI agent CI/CD reprodukovateľné aj vtedy, keď pôvodné sedenie agenta už neexistuje.

Referenciu Dockup CLI považujte za autoritatívny zdroj príkazov. Ak chcete vytvoriť repozitár ešte pred povolením CI, postupujte podľa článku Od Git repozitára po produkčné nasadenie.

Kontrolujte súbežnosť a propagáciu medzi prostrediami

Dve úspešné pipeline môžu stále vytvoriť nebezpečné vydanie, ak bežia súbežne nad tým istým cieľom. Použite riadenie súbežnosti CI platformy, aby novší produkčný job buď počkal na starší, alebo ho zámerne nahradil. Dockup pravdivo zaznamená každé nasadenie, no o poradí prekrývajúcich sa commitov musí rozhodnúť workflow repozitára.

Medzi prostrediami propagujte ten istý skontrolovaný commit namiesto opätovného buildu nesledovaného lokálneho stavu. Staging job môže nasadiť staging/api, spustiť kontroly aplikácie a následne povoliť chránenému produkčnému jobu nasadiť production/api. Tokeny a ciele udržiavajte oddelené, aby staging agent omylom neprekročil túto hranicu.

Definujte politiku opakovania pri timeoutoch

deploy_timeout neznamená zlyhanie ani úspech. Znamená, že operácia stále prebiehala po uplynutí 900-sekundového čakania. Pred opakovaním skontrolujte:

dockup status production/api --json
dockup deployments production/api -n 5 --json

Ak pôvodné nasadenie neskôr dosiahlo úspech, slepé opakovanie by vytvorilo ďalšie vydanie. Ak zlyhalo, zhromaždite build log. Ak stále nemá konečný stav a build je legitímne dlhý, zopakujte sledovanie s väčším zdokumentovaným timeoutom namiesto vytvorenia druhého nasadenia.

Toto rozlíšenie bráni tomu, aby sa AI agent CI/CD zmenilo sieťovú alebo časovú neistotu na duplicitné produkčné zmeny.

Zaznamenajte identitu nasadenia

Do súhrnu CI zahrňte identitu účtu Dockup, cieľ, commit SHA, ID nasadenia a konečný status. Tento stručný záznam umožní neskoršiemu operátorovi prepojiť beh pipeline s auditnými udalosťami Dockup bez odhalenia tokenu.

Uveďte workflow do produkcie

Nainštalujte CLI na runneri, overte injektovanú identitu a za bránu pipeline nastavte konečný exit status, nie riadok logu vyzerajúci ako úspech.

npm install -g dockup-cli
dockup skill install

Prvý príkaz nainštaluje CLI. Druhý nainštaluje zodpovedajúci Dockup skill pre Claude Code a Codex. Začnite bezplatne na app.dockup.ai.

Často kladené otázky

Čo je DOCKUP_TOKEN?

DOCKUP_TOKEN je autentifikačná cesta založená na premennej prostredia pre relácie Dockup CLI, ktoré nemôžu dokončiť interaktívne prihlásenie v prehliadači, vrátane CI runnerov, kontajnerov a AI agentov.

Prepíše DOCKUP_TOKEN lokálny konfiguračný súbor Dockup?

Áno. Token z prostredia má prednosť a dockup whoami --json uvádza aktívny zdroj tokenu.

Ako CI job zistí, že nasadenie Dockup zlyhalo?

Spustite dockup deploy s --wait a --json. Príkaz pri zlyhaní alebo timeout-e nasadenia skončí s nenulovým exit code a štruktúrovaným kódom zlyhania.

Mal by CI workflow pri ladení vypísať token na nasadenie?

Nie. Uchovávajte ho v úložisku tajomstiev CI, vyhnite sa shell tracingu a výpisom prostredia a sprístupnite ho iba kroku nasadenia.

Môžu Claude Code alebo Codex používať rovnakú autentifikačnú cestu CI?

Áno. Oba môžu používať DOCKUP_TOKEN a pribalený Dockup skill, ktorý ich učí rovnaké pravidlá pre JSON, vyhľadávanie cieľa, čakanie a schvaľovanie.