AI agent CI/CD s DOCKUP_TOKENOM

AI agent CI/CD uspješan je samo kada autentikacija i deployment ispravno funkcioniraju bez osobe za terminalom. Prijava u pregledniku, ručno kopiranje jednokratnih kodova i poruke o statusu napisane samo u obliku teksta nisu kompatibilni s unattended runnerom. Dockup podržava neinteraktivni način rada putem DOCKUP_TOKEN, strukturiranog JSON-a i deploy naredbi koje vraćaju stvarni izlazni kod greške.

Ovaj vodič definira ugovor pipelinea koji mogu koristiti Claude Code, Codex, shell skripta ili uobičajeni CI job. Pravila su ista: token se ubacuje tijekom izvođenja, provjerava se identitet, otkriva se ili navodi točan target, čeka se terminalni rezultat, a dijagnostički podaci čuvaju se u slučaju greške.

Zašto AI agent CI/CD treba neinteraktivnu autentikaciju?

Interaktivna naredba dockup login otvara stranicu za autentikaciju i čeka token. To je primjereno za developersku radnu stanicu, ali containerizirani runner možda nema preglednik, trajni home direktorij ni osobu koja bi nešto ručno zalijepila.

DOCKUP_TOKEN rješava tu granicu:

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

Varijabla okruženja ima prednost pred ~/.dockup/config.json. whoami prijavljuje tokenSource, pa pipeline može dokazati da koristi namjerno ubačeni credential, a ne stari konfiguracijski zapis koji je ostao na self-hosted runneru.

U CI-ju nemojte pokretati dockup login -t "$DOCKUP_TOKEN" osim ako postoji poseban razlog za trajno spremanje konfiguracijske datoteke. Izravno prosljeđivanje varijable okruženja ograničava credential na proces i sprječava njegovo zapisivanje u home direktorij runnera.

Pipeline nikada ne smije ispisati token. Isključite shell tracing oko naredbi koje sadrže tajne, nemojte ispisivati cijelo okruženje i koristite mogućnost CI platforme za maskiranje tajni.

Kako spremiti i ograničiti DOCKUP_TOKEN?

Token spremite kao enkriptiranu tajnu repozitorija, okruženja ili organizacije. Za production preferirajte tajnu na razini okruženja jer se može kombinirati s ograničenjima grana i ručnim odobrenjima koje pruža CI platforma.

Sigurna politika za tokene odgovara na pet pitanja:

Pitanje	Preporučeni odgovor
Gdje je token spremljen?	CI spremište enkriptiranih tajni
Kada je izložen?	Samo u deployment jobu
Koje ga grane mogu koristiti?	Zaštićene production grane
Tko može mijenjati workflow?	Maintaineri čije su promjene pregledane
Kako se upotreba provjerava?	Dockup audit log i povijest CI jobova

Dockup podržava i API ključeve s definiranim dopuštenjima. Prije izrade usko ograničenog ključa izlistajte dostupna imena dopuštenja:

dockup keys permissions --json

Odaberite samo točna imena dopuštenja koja platforma vrati, a zatim izradite ključ kroz workflow za API ključeve s dopuštenjima. Generirani ključ sigurno preuzmite tijekom izrade i odmah ga spremite; nemojte ga uključivati u issue, pull request ili transcript agenta. Deployment job ne bi trebao naslijediti široke administratorske ovlasti nad računom samo zato što ih developerski token već ima.

Članak AI agent production guardrails pruža širi model razina dopuštenja.

Kako izgraditi deployment pipeline koji čeka stvarni rezultat?

Instalirajte CLI u jobu, provjerite identitet, a zatim pokrenite deployment s opcijom --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

Važan dio nije CI vendor, nego ugovor naredbe. dockup deploy ... --wait --json vraća 0 samo kada deployment dosegne stanje uspjeha. Zadani timeout iznosi 900 sekundi. Neuspješna izgradnja vraća izlaz različit od nule s kodom deploy_failed, a operacija koja do isteka timeouta ne dosegne terminalno stanje vraća deploy_timeout.

Budući da proces završava izlazom različitim od nule, runner označava korak i job kao neuspješne. Nije potrebno parsirati logove.

Za povezani repozitorij koji treba poslati svoju trenutačnu granu i pokrenuti deployment, dockup push --json prema zadanim postavkama čeka završetak. U CI jobu koji je već primio Git push event, eksplicitni dockup deploy <target> često je jasniji jer izbjegava slanje promjena s runnera.

Kako pipeline treba prikupljati logove i kodove grešaka?

Sačuvajte JSON rezultat deploymenta kao artifact ili output joba, ali pazite da preusmjeravanje ne sakrije izlazni status. Shell pattern može zabilježiti 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 završava s izvornim statusom deploymenta. Build logovi prikupljaju se samo nakon greške. Runtime logove treba prikupljati kada je image izgrađen, ali se aplikacija poslije sruši:

dockup logs production/api --json

Za vidljivost builda uživo, follow mode emitira NDJSON:

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

Stream završava kada i deployment, a greška i dalje rezultira izlazom procesa različitim od nule. Detaljan slijed dijagnostike obrađen je u članku otklanjanje grešaka u build i runtime logovima.

Pipeline se treba granati prema kodovima, a ne fragmentima poruka:

Kod	Reakcija pipelinea
not_logged_in	Odmah prekinuti; ubacivanje tajne ne funkcionira
no_target	Prekinuti; konfiguracija targeta nije valjana
deploy_trigger_failed	Prekinuti prije čekanja; provjeriti vraćenu grešku
deploy_failed	Prenijeti build logove i prekinuti
deploy_timeout	Označiti kao neizvjesno; provjeriti status prije ponovnog pokušaja
needs_confirm	Zaustaviti; destruktivnom koraku nedostaje odobrenje

Kako agent može sudjelovati bez slabljenja CI sigurnosti?

Agent može pripremiti kod, ažurirati pregledani workflow, interpretirati JSON i sažeti neuspješni build. Ne treba imati neograničen pristup production tokenu u svakoj coding sesiji.

Odvojite uloge:

1. Development agent: lokalno uređuje kod i testove.
2. Review process: provjerava promjene deployment konfiguracije.
3. CI runner: prima DOCKUP_TOKEN tek nakon odobrenog triggera.
4. Dockup: izvršava deployment i bilježi audit evente.
5. Agent ili operator: interpretira rezultat i predlaže oporavak.

Ovakav raspored sprječava da prompt injection u nepovezanom zadatku dođe do production credentiala. Agent i dalje može razumjeti pipeline jer su naredbe i očekivani JSON spremljeni u repozitoriju, dok vrijednost tajne ostaje izvan njega.

Za deploy koji agent pokreće izravno, ubacite token u određeni Claude Code ili Codex proces i instalirajte uključeni skill:

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

Skill upućuje oba agenta na neinteraktivnu autentikaciju, JSON, otkrivanje točnog targeta, čekanje na terminalno stanje i potvrde za osjetljive korake.

Što AI agent CI/CD čini ponovljivim i provjerljivim?

Ponovljivost počinje eksplicitnim targetom. production/api spremite kao zaštićenu varijablu pipelinea ili kao pregledani literal, a ne kao naziv koji agent izvodi tijekom izvođenja. Provjerite račun prije prvog upisa.

Idempotentnost zahtijeva različit pristup ovisno o operaciji:

• Ponovljeno čitanje identiteta, statusa, logova i povijesti sigurno je.
• Izrada servisa mora početi otkrivanjem targeta kako ponovni pokušaji ne bi izradili duplikat.
• Ponovni deployment stvara novi production event i treba ga zabilježiti.
• Promjene okruženja su mutacije i zahtijevaju redeploy.
• Destrukcija i pruning ne smiju biti automatski ciljevi ponovnog pokušaja.

Nakon deploymenta prikupite dokaze s platforme:

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

Uptime se mjeri svake minute i uključuje prosječno vrijeme odziva te p95 vrijeme odziva. Audit output povezuje CI mutaciju s kasnijim pregledom. Potrošnja CPU-a, RAM-a i diska također se mjeri svake minute u odnosu na stanje računa; preporučeni Pro plan iznosi 20 USD mjesečno uz kredit za upotrebu od 20 USD.

Potpuni zapis pipelinea uključuje Git commit, Dockup target, ID deploymenta, vrijeme početka i završetka, izlazni kod, terminalni status i poveznice na build artefakte. Tako je AI agent CI/CD release reproducibilan čak i kada izvorna sesija agenta više ne postoji.

Dokumentaciju Dockup CLI-ja treba smatrati mjerodavnim izvorom za naredbe. Za izradu repozitorija prije uključivanja CI-ja slijedite vodič Od Git repozitorija do production deploymenta.

Kontrolirajte concurrency i promociju između okruženja

Dva uspješna pipelinea i dalje mogu stvoriti nesiguran release ako istodobno rade nad istim targetom. Upotrijebite concurrency kontrole CI platforme kako bi noviji production job pričekao stariji ili ga namjerno zamijenio. Dockup će istinito prijaviti svaki deployment, ali workflow repozitorija mora odlučiti kojim se redoslijedom obrađuju preklapajući commitovi.

Promovirajte isti pregledani commit između okruženja umjesto ponovne izgradnje nespremljenog lokalnog stanja. Staging job može pokrenuti deployment na staging/api, izvršiti provjere aplikacije, a zatim omogućiti zaštićenom production jobu deployment na production/api. Tokene i targete držite odvojenima kako staging agent slučajno ne bi prešao granicu.

Definirajte politiku ponovnog pokušaja nakon timeouta

deploy_timeout ne znači ni neuspjeh ni uspjeh. Znači da je operacija još trajala kada je čekanje od 900 sekundi završilo. Prije ponovnog pokušaja provjerite:

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

Ako je izvorni deployment poslije dosegnuo uspjeh, slijepi ponovni pokušaj stvorio bi još jedan release. Ako nije uspio, prikupite build log. Ako i dalje nije dosegnuto terminalno stanje, a build je legitimno dugotrajan, ponovite promatranje s većim, dokumentiranim timeoutom umjesto izrade drugog deploymenta.

Ova razlika sprječava da AI agent CI/CD mrežnu ili vremensku neizvjesnost pretvori u duplicirane production promjene.

Zabilježite identitet deploymenta

U CI sažetak uključite identitet Dockup računa, target, commit SHA, ID deploymenta i terminalni status. Ovaj mali zapis kasnijem operatoru omogućuje povezivanje izvođenja pipelinea s Dockup audit eventima bez izlaganja tokena.

Uvedite workflow u production

Instalirajte CLI na runner, provjerite ubačeni identitet i neka terminalni izlazni status — a ne redak loga koji izgleda kao poruka o uspjehu — bude gate pipelinea.

npm install -g dockup-cli
dockup skill install

Prva naredba instalira CLI. Druga instalira odgovarajući Dockup skill za Claude Code i Codex. Započnite besplatno na app.dockup.ai.

Česta pitanja

Što je DOCKUP_TOKEN?

DOCKUP_TOKEN je način autentikacije temeljen na varijabli okruženja za Dockup CLI sesije koje ne mogu dovršiti interaktivnu prijavu u pregledniku, uključujući CI runnere, containere i AI agente.

Nadjačava li DOCKUP_TOKEN lokalnu Dockup konfiguracijsku datoteku?

Da. Token iz okruženja ima prednost, a naredba dockup whoami --json prijavljuje aktivni izvor tokena.

Kako CI job zna da Dockup deployment nije uspio?

Pokrenite dockup deploy s opcijama --wait i --json. Naredba završava izlazom različitim od nule i strukturiranim kodom greške kada deployment ne uspije ili istekne timeout.

Treba li CI workflow ispisati deployment token radi otklanjanja grešaka?

Ne. Držite ga u CI spremištu tajni, izbjegavajte shell tracing i ispise okruženja te ga izložite samo deployment koraku.

Mogu li Claude Code ili Codex koristiti isti CI način autentikacije?

Da. Oba mogu koristiti DOCKUP_TOKEN i uključeni Dockup skill, koji ih uči istim pravilima za JSON, otkrivanje targeta, čekanje i potvrde.