AI-agent CI/CD med DOCKUP_TOKEN

AI-agent CI/CD fungerer kun, når godkendelse og deployment fungerer korrekt uden en person ved terminalen. Browserlogin, kopierede engangskoder og statusbeskeder i prosa er uforenelige med en runner, der kører uden opsyn. Dockup understøtter den ikke-interaktive arbejdsgang via DOCKUP_TOKEN, struktureret JSON og deploy-kommandoer, der returnerer en reel fejlstatus.

Denne guide opbygger en pipeline-kontrakt, som Claude Code, Codex, et shell-script eller et traditionelt CI-job kan bruge. De samme regler gælder: injicér tokenet ved runtime, verificér identiteten, find eller angiv det præcise target, vent på et endeligt resultat, og bevar diagnostik ved fejl.

Hvorfor har AI-agent CI/CD brug for ikke-interaktiv godkendelse?

Interaktiv dockup login åbner en godkendelsesside og venter på et token. Det er passende på en udviklercomputer, men en containeriseret runner har muligvis ingen browser, ingen permanent home-mappe og ingen person til at indsætte noget.

DOCKUP_TOKEN løser denne grænse:

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

Miljøvariablen har forrang over ~/.dockup/config.json. whoami rapporterer tokenSource, så pipelinen kan dokumentere, at den bruger den tilsigtede injicerede credential i stedet for en gammel konfigurationsfil, der ligger tilbage på en self-hosted runner.

Kør ikke dockup login -t "$DOCKUP_TOKEN" i CI, medmindre der er en specifik grund til at gemme en konfigurationsfil. Hvis miljøvariablen angives direkte, begrænses credentialen til processen, og man undgår at skrive den til runnerens home-mappe.

Pipelinen må aldrig udskrive tokenet. Deaktivér shell tracing omkring kommandoer, der indeholder secrets, undgå at udskrive hele miljøet, og brug CI-platformens funktion til maskering af secrets.

Hvordan skal DOCKUP_TOKEN gemmes og begrænses?

Gem tokenet som en krypteret repository-, miljø- eller organisations-secret. Foretræk en secret på miljøniveau til produktion, fordi den kan kombineres med branch restrictions og manuelle godkendelser fra CI-platformen.

En sikker tokenpolitik besvarer fem spørgsmål:

Spørgsmål	Anbefalet svar
Hvor gemmes tokenet?	CI-platformens krypterede secret-lager
Hvornår eksponeres det?	Kun i deployment-jobbet
Hvilke branches kan bruge det?	Beskyttede produktionsbranches
Hvem kan ændre workflowet?	Maintainers, hvis ændringer gennemgås
Hvordan gennemgås brugen?	Dockup audit-log plus CI-jobhistorik

Dockup understøtter også API keys med permissions. Se først de tilgængelige permission-navne, før du opretter en nøgle med begrænset scope:

dockup keys permissions --json

Vælg kun de nøjagtige permission-navne, som platformen returnerer, og opret derefter nøglen via workflowet for API keys med permissions. Håndtér den genererede nøgle sikkert under oprettelsen, gem den med det samme, og medtag den ikke i en issue, pull request eller agenttransskription; et deployment-job bør ikke arve omfattende kontoadministration, blot fordi et udviklertoken allerede har disse permissions.

Artiklen sikkerhedsforanstaltninger til AI-agenter i produktion beskriver en bredere permissions-model.

Hvordan bygger man en deployment-pipeline, der venter på det faktiske resultat?

Installér CLI'et i jobbet, verificér identiteten, og deploy derefter 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 vigtige er ikke CI-leverandøren, men kommandoens kontrakt. dockup deploy ... --wait --json afsluttes med 0, kun når deployment når frem til en succesfuld tilstand. Standard-timeout er 900 sekunder. Et fejlet build returnerer en status forskellig fra nul sammen med deploy_failed; en operation, der ikke når en terminaltilstand inden timeout, returnerer deploy_timeout.

Da processen afsluttes med en status forskellig fra nul, markerer runneren steppet og jobbet som fejlet. Der er ikke behov for at analysere logs.

For et linket repository, der skal pushe sin aktuelle branch og deploye, venter dockup push --json som standard. I et CI-job, der allerede har modtaget en Git push-event, er en eksplicit dockup deploy <target> ofte tydeligere, fordi den undgår at pushe fra runneren.

Hvordan skal en pipeline opsamle logs og fejlkoder?

Bevar JSON-resultatet fra deployment som et artifact eller job-output, men sørg for, at en redirect ikke skjuler exit-statussen. Et shell-mønster kan opsamle begge dele:

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 afsluttes med den oprindelige deploy-status. Build-logs opsamles kun efter en fejl. Runtime-logs bør opsamles, når imaget er bygget, men applikationen senere crasher:

dockup logs production/api --json

For live build-indsigt udsender follow mode NDJSON:

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

Streamen afsluttes, når deploymentet gør det, og en fejl forbliver et procesresultat forskelligt fra nul. Den detaljerede diagnostiksekvens er beskrevet i fejlfinding af build- og runtime-logs.

En pipeline bør forgrene på koder, ikke på tekststumper fra beskeder:

Kode	Pipeline-reaktion
not_logged_in	Fejl med det samme; injicering af secret er brudt
no_target	Fejl; target-konfigurationen er ugyldig
deploy_trigger_failed	Fejl før ventetid; undersøg den returnerede fejl
deploy_failed	Upload build-logs, og markér jobbet som fejlet
deploy_timeout	Markér status som uafklaret; undersøg status før retry
needs_confirm	Stop; et destruktivt trin mangler godkendelse

Hvordan kan en agent deltage uden at svække CI-sikkerheden?

En agent kan forberede kode, opdatere et workflow, der skal gennemgås, fortolke JSON og opsummere et fejlet build. Den behøver ikke ubegrænset adgang til production-tokenet i hver coding-session.

Adskil rollerne:

1. Udviklingsagent: redigerer kode og kører tests lokalt.
2. Review-proces: validerer ændringer i deployment-konfigurationen.
3. CI-runner: modtager kun DOCKUP_TOKEN, efter at triggeren er godkendt.
4. Dockup: udfører deploymentet og registrerer audit-events.
5. Agent eller operatør: fortolker resultatet og foreslår genopretning.

Denne opbygning forhindrer, at prompt injection i en anden opgave får adgang til produktionscredentials. Agenten kan stadig forstå pipelinen, fordi kommandoerne og den forventede JSON er committet, mens secret-værdien forbliver uden for repositoryet.

Ved direkte agentstyrede deployments skal tokenet injiceres i den specifikke Claude Code- eller Codex-proces, og den medfølgende skill skal installeres:

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

Skill'en instruerer begge agenter i at bruge ikke-interaktiv godkendelse, JSON, præcis target discovery, ventetid på terminalstatus og godkendelsesgates.

Hvad gør AI-agent CI/CD reproducerbar og auditerbar?

Reproducerbarhed begynder med et eksplicit target. Gem production/api som en beskyttet pipeline-variabel eller en literal, der er gennemgået, i stedet for at lade agenten udlede et navn ved runtime. Validér kontoen før den første skrivehandling.

Idempotens kræver forskellig håndtering afhængigt af operationen:

• Det er sikkert at gentage læsning af identitet, status, logs og historik.
• Oprettelse af services skal begynde med target discovery, så retries ikke opretter en dublet.
• Et nyt deployment opretter endnu en produktionsevent og bør registreres.
• Ændringer i miljøet er mutationer og kræver et nyt deployment.
• Destruktion og pruning må ikke være automatiske retry-mål.

Indsaml platformens dokumentation efter deployment:

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

Uptime måles hvert minut og omfatter gennemsnitlig responstid og p95-responstid. Audit-output forbinder CI-mutationen med den efterfølgende gennemgang. CPU-, RAM- og diskforbrug måles også hvert minut i forhold til kontoens saldo; den anbefalede Pro-plan koster 20 USD om måneden med 20 USD i usage credit.

En komplet pipeline-registrering indeholder Git-commit, Dockup-target, deployment-ID, start- og sluttidspunkter, exit-kode, terminalstatus og links til build-artifacts. Det gør en AI-agent CI/CD-release reproducerbar, selv når den oprindelige agentsession er væk.

Dockup CLI-reference bør betragtes som den autoritative kilde til kommandoerne. Hvis et repository skal oprettes, før CI aktiveres, kan du følge fra Git-repository til produktion.

Styr concurrency og promovering mellem miljøer

To succesfulde pipelines kan stadig skabe en usikker release, hvis de kører samtidigt mod det samme target. Brug CI-platformens concurrency-kontroller, så et nyere produktionsjob enten venter på eller bevidst erstatter et ældre job. Dockup rapporterer sandfærdigt hvert deployment, men repository-workflowet skal beslutte, hvordan overlappende commits ordnes.

Promovér den samme gennemgåede commit mellem miljøer i stedet for at bygge en uregistreret lokal tilstand igen. Et staging-job kan deploye staging/api, køre applikationstests og derefter tillade et beskyttet produktionsjob at deploye production/api. Hold tokens og targets adskilt, så en staging-agent ikke ved en fejl kan krydse grænsen.

Definér en retry-politik for timeouts

deploy_timeout betyder hverken fejl eller succes. Det betyder, at operationen stadig kørte, da ventetiden på 900 sekunder udløb. Undersøg følgende, før du prøver igen:

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

Hvis det oprindelige deployment senere nåede frem til succes, vil et blindt retry oprette endnu en release. Hvis det fejlede, skal build-loggen indsamles. Hvis det stadig ikke har nået en terminaltilstand, og buildet legitimt tager lang tid, skal du køre observationen igen med en længere, dokumenteret timeout i stedet for at oprette et nyt deployment.

Denne sondring forhindrer, at AI-agent CI/CD forvandler netværks- eller timing-usikkerhed til dublerede produktionsændringer.

Registrér deploymentets identitet

Medtag Dockup-kontoens identitet, target, commit-SHA, deployment-ID og terminalstatus i CI-opsummeringen. Denne lille registrering gør det muligt for en senere operatør at forbinde pipeline-kørslen med Dockup-audit-events uden at eksponere tokenet.

Gør workflowet klar til produktion

Installér CLI'et på runneren, verificér den injicerede identitet, og lad terminalens exit-status – ikke en loglinje, der ser succesfuld ud – være pipelinens gate.

npm install -g dockup-cli
dockup skill install

Den første kommando installerer CLI'et. Den anden installerer den matchende Dockup-skill til Claude Code og Codex. Kom gratis i gang på app.dockup.ai.

FAQ

Hvad er DOCKUP_TOKEN?

DOCKUP_TOKEN er den miljøbaserede godkendelsesmetode til Dockup CLI-sessioner, der ikke kan gennemføre interaktivt browserlogin, herunder CI-runners, containere og AI-agenter.

Tilsidesætter DOCKUP_TOKEN en lokal Dockup-konfigurationsfil?

Ja. Miljøtokenet har forrang, og dockup whoami --json rapporterer den aktive token-kilde.

Hvordan ved et CI-job, at et Dockup-deployment fejlede?

Kør dockup deploy med --wait og --json. Kommandoen afsluttes med en status forskellig fra nul og en struktureret fejlkode, når deploymentet fejler eller får timeout.

Bør et CI-workflow udskrive deployment-tokenet til debugging?

Nej. Opbevar det i CI-secret-lageret, undgå shell tracing og miljø-dumps, og eksponér det kun for deployment-steppet.

Kan Claude Code eller Codex bruge den samme CI-godkendelsesmetode?

Ja. Begge kan bruge DOCKUP_TOKEN og den medfølgende Dockup-skill, som lærer dem de samme regler for JSON, target discovery, ventetid og godkendelse.