AI-agent CI/CD med DOCKUP_TOKEN

AI-agent CI/CD fungerer bare når autentisering og distribusjon oppfører seg riktig uten at noen sitter ved terminalen. Nettleserinnlogging, kopierte engangskoder og statusmeldinger som bare består av tekst, er uforenlige med en unattended runner. Dockup støtter den ikke-interaktive arbeidsflyten gjennom DOCKUP_TOKEN, strukturert JSON og deploy-kommandoer som returnerer en reell feilkode.

Denne veiledningen etablerer en pipeline-kontrakt som Claude Code, Codex, et shell-skript eller en konvensjonell CI-jobb kan bruke. De samme reglene gjelder: injiser tokenet ved kjøring, bekreft identiteten, finn eller spesifiser det nøyaktige målet, vent på et terminalresultat og ta vare på diagnostikk ved feil.

Hvorfor trenger AI-agent CI/CD ikke-interaktiv autentisering?

Interaktiv dockup login åpner en autentiseringsside og venter på et token. Det passer på en utviklermaskin, men en containerisert runner har kanskje ingen nettleser, ingen permanent hjemmekatalog og ingen person som kan lime inn noe.

DOCKUP_TOKEN løser denne grenseflaten:

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

Miljøvariabelen har prioritet over ~/.dockup/config.json. whoami rapporterer tokenSource, slik at pipelinen kan dokumentere at den bruker den tiltenkte injiserte legitimasjonen, i stedet for en gammel konfigurasjonsfil som ligger igjen på en self-hosted runner.

Ikke kjør dockup login -t "$DOCKUP_TOKEN" i CI med mindre det finnes en spesifikk grunn til å lagre en konfigurasjonsfil. Når miljøvariabelen oppgis direkte, holdes legitimasjonen begrenset til prosessen, og du unngår å skrive den til runnerens hjemmekatalog.

Pipelinen må aldri skrive ut tokenet. Deaktiver shell tracing rundt kommandoer som håndterer secrets, unngå å skrive ut hele miljøet, og bruk CI-plattformens funksjon for maskering av secrets.

Hvordan bør DOCKUP_TOKEN lagres og begrenses?

Lagre tokenet som en kryptert repository-, miljø- eller organisasjonshemmelighet. Foretrekk en hemmelighet på miljønivå for produksjon, fordi den kan kombineres med branch-begrensninger og manuelle godkjenninger som tilbys av CI-plattformen.

En sikker token-policy bør besvare fem spørsmål:

Spørsmål	Anbefalt svar
Hvor lagres tokenet?	CI-plattformens krypterte secret store
Når eksponeres det?	Bare i deployment-jobben
Hvilke branches kan bruke det?	Beskyttede produksjonsbranches
Hvem kan endre workflowen?	Maintainers som har gjennomgått endringen
Hvordan gjennomgås bruken?	Dockup audit-logg samt historikken for CI-jobben

Dockup støtter også API-nøkler med tilgangsstyring. List tilgjengelige tillatelsesnavn før du oppretter en nøkkel med begrenset tilgang:

dockup keys permissions --json

Velg bare eksakte tillatelsesnavn som plattformen returnerer, og opprett deretter nøkkelen gjennom arbeidsflyten for API-nøkler med tilgangsstyring. Ta vare på den genererte nøkkelen på en sikker måte under opprettelsen, lagre den umiddelbart, og ikke inkluder den i en issue, pull request eller agenttranskripsjon; en deployment-jobb bør ikke arve bred kontoadministrasjon bare fordi et utviklertoken allerede har denne tilgangen.

Artikkelen sikkerhetsregler for AI-agenter i produksjon beskriver en bredere tilgangsstige.

Hvordan bygger du en deployment-pipeline som venter på sannheten?

Installer CLI-et i jobben, bekreft identiteten, og distribuer deretter med --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

Det viktige er ikke hvilken CI-leverandør du bruker, men kommandoens kontrakt. dockup deploy ... --wait --json avslutter med 0 bare når distribusjonen når statusen vellykket. Standard-timeouten er 900 sekunder. Et mislykket build returnerer en feilkode med deploy_failed; en operasjon som ikke har nådd en terminaltilstand innen timeouten, returnerer deploy_timeout.

Fordi prosessen avslutter med en feilkode, markerer runneren steget og jobben som mislykket. Det er ikke nødvendig å analysere logger.

For et koblet repository som skal pushe den gjeldende branchen og distribuere, venter dockup push --json som standard. I en CI-jobb som allerede har mottatt en Git push-hendelse, er en eksplisitt dockup deploy <target> ofte tydeligere, fordi den unngår å pushe fra runneren.

Hvordan bør en pipeline ta vare på logger og feilkoder?

Ta vare på JSON-resultatet fra distribusjonen som et artifact eller jobbutdata, men unngå at en omdirigering skjuler exit-statusen. Et shell-mønster kan fange opp begge deler:

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

Pipelinen avslutter med den opprinnelige deploy-statusen. Build-logger hentes bare etter en feil. Runtime-logger bør hentes når imaget ble bygget, men applikasjonen senere krasjer:

dockup logs production/api --json

For løpende innsyn i buildet sender follow-modus ut NDJSON:

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

Strømmen avsluttes når distribusjonen gjør det, og feil resulterer fortsatt i en prosess som avslutter med en feilkode. Den detaljerte diagnostikksekvensen er beskrevet i feilsøking av build- og runtime-logger.

En pipeline bør styre flyten basert på koder, ikke tekstfragmenter fra meldinger:

Kode	Respons i pipelinen
not_logged_in	Feil umiddelbart; injisering av secret fungerer ikke
no_target	Feil; målkonfigurasjonen er ugyldig
deploy_trigger_failed	Feil før venting; undersøk feilen som ble returnert
deploy_failed	Last opp build-logger og marker jobben som mislykket
deploy_timeout	Marker som usikker; undersøk status før du prøver på nytt
needs_confirm	Stopp; et destruktivt steg mangler godkjenning

Hvordan kan en agent delta uten å svekke CI-sikkerheten?

En agent kan klargjøre kode, oppdatere en workflow som skal gjennomgås, tolke JSON og oppsummere et mislykket build. Den trenger ikke ubegrenset tilgang til produksjonstokenet i hver kodingsøkt.

Skill mellom rollene:

1. Utviklingsagent: endrer kode og kjører tester lokalt.
2. Review-prosess: validerer endringer i deployment-konfigurasjonen.
3. CI-runner: mottar DOCKUP_TOKEN først etter at en godkjent trigger er kjørt.
4. Dockup: utfører distribusjonen og registrerer audit-hendelser.
5. Agent eller operatør: tolker resultatet og foreslår gjenoppretting.

Denne organiseringen hindrer at prompt injection i en urelatert oppgave får tilgang til produksjonslegitimasjon. Agenten kan fortsatt forstå pipelinen fordi kommandoene og forventet JSON er lagret i repositoryet, mens selve secret-verdien forblir utenfor repositoryet.

For distribusjoner som kjøres direkte av en agent, injiser tokenet i den spesifikke Claude Code- eller Codex-prosessen, og installer den medfølgende skill-en:

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

Skill-en instruerer begge agentene til å bruke ikke-interaktiv autentisering, JSON, oppslag av eksakt mål, venting på terminaltilstand og godkjenningsporter.

Hva gjør AI-agent CI/CD repeterbar og etterprøvbar?

Repeterbarhet begynner med et eksplisitt mål. Lagre production/api som en beskyttet pipeline-variabel eller en gjennomgått literal, ikke som et navn agenten utleder ved kjøring. Valider kontoen før den første skriveoperasjonen.

Idempotens krever ulik behandling avhengig av operasjonen:

• Det er trygt å gjenta lesing av identitet, status, logger og historikk.
• Oppretting av en tjeneste må begynne med oppslag av målet, slik at retries ikke oppretter en duplikat.
• En ny deploy oppretter en ny produksjonshendelse og bør registreres.
• Endringer i miljøet er mutasjoner og krever en ny deploy.
• Destruksjon og pruning må ikke være automatiske mål for retries.

Etter distribusjonen henter du bevis fra plattformen:

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

Oppetid måles hvert minutt og inkluderer gjennomsnittlig responstid og p95-responstid. Audit-utdata knytter CI-mutasjonen til senere gjennomgang. CPU-, RAM- og diskforbruk måles også per minutt opp mot kontosaldoen; den anbefalte Pro-planen koster 20 dollar per måned og inkluderer 20 dollar i brukskreditt.

En komplett pipeline-post inneholder Git-commit, Dockup-mål, deployment-ID, start- og sluttidspunkt, exit-kode, terminalstatus og lenker til build-artifacts. Dette gjør en AI-agent CI/CD-release reproduserbar selv når den opprinnelige agentøkten er borte.

Dockup CLI-referansen bør behandles som autoritativ for kommandoene. Følg fra Git-repository til produksjon for å opprette repositoryet før CI aktiveres.

Kontroller samtidighet og promotering mellom miljøer

To vellykkede pipelines kan likevel skape en utrygg release hvis de kjører samtidig mot samme mål. Bruk CI-plattformens concurrency-kontroller slik at en nyere produksjonsjobb enten venter på eller bevisst erstatter en eldre jobb. Dockup rapporterer sannferdig om hver distribusjon, men repository-workflowen må avgjøre rekkefølgen på overlappende commits.

Promoter den samme gjennomgåtte commiten mellom miljøer i stedet for å bygge en lokal tilstand som ikke er sporet. En staging-jobb kan distribuere staging/api, kjøre applikasjonskontroller og deretter tillate at en beskyttet produksjonsjobb distribuerer production/api. Hold tokens og mål adskilt, slik at en staging-agent ikke utilsiktet kan krysse grensen.

Definer en retry-policy for timeouts

deploy_timeout betyr verken feil eller suksess. Det betyr at operasjonen fortsatt kjørte da ventingen på 900 sekunder utløp. Undersøk dette før du prøver på nytt:

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

Hvis den opprinnelige distribusjonen senere nådde statusen vellykket, vil en blind retry opprette en ny release. Hvis den mislyktes, henter du build-loggen. Hvis den fortsatt ikke har nådd en terminaltilstand og buildet legitimt tar lang tid, kjører du observasjonen på nytt med en større, dokumentert timeout i stedet for å opprette en ny distribusjon.

Dette skillet hindrer AI-agent CI/CD i å gjøre nettverks- eller tidsusikkerhet om til dupliserte produksjonsendringer.

Registrer distribusjonens identitet

Inkluder Dockup-kontoens identitet, mål, commit-SHA, deployment-ID og terminalstatus i CI-sammendraget. Denne lille posten gjør det mulig for en senere operatør å koble pipeline-kjøringen til Dockup-audit-hendelser uten å eksponere tokenet.

Sett workflowen i produksjon

Installer CLI-et på runneren, bekreft den injiserte identiteten, og la terminalens exit-status – ikke en logglinje som ser vellykket ut – være porten som avgjør om pipelinen godkjennes.

npm install -g dockup-cli
dockup skill install

Den første kommandoen installerer CLI-et. Den andre installerer den tilhørende Dockup-skill-en for Claude Code og Codex. Kom i gang gratis på app.dockup.ai.

Vanlige spørsmål

Hva er DOCKUP_TOKEN?

DOCKUP_TOKEN er den miljøbaserte autentiseringsmåten for Dockup CLI-økter som ikke kan fullføre interaktiv nettleserinnlogging, inkludert CI-runnere, containere og AI-agenter.

Overstyrer DOCKUP_TOKEN en lokal Dockup-konfigurasjonsfil?

Ja. Miljøtokenet har prioritet, og dockup whoami --json rapporterer den aktive tokenkilden.

Hvordan vet en CI-jobb at en Dockup-distribusjon mislyktes?

Kjør dockup deploy med --wait og --json. Kommandoen avslutter med en feilkode og en strukturert feilkode når deployen mislykkes eller får timeout.

Bør en CI-workflow skrive ut deployment-tokenet for feilsøking?

Nei. Oppbevar det i CI-plattformens secret store, unngå shell tracing og dumps av miljøet, og eksponer det bare for deployment-steget.

Kan Claude Code eller Codex bruke den samme CI-autentiseringsmåten?

Ja. Begge kan bruke DOCKUP_TOKEN og den medfølgende Dockup-skill-en, som lærer bort de samme reglene for JSON, oppslag av mål, venting og godkjenning.