AI-agenters CI/CD med DOCKUP_TOKEN

AI-agenters CI/CD fungerar bara när autentisering och distribution fungerar korrekt utan att någon behöver sitta vid terminalen. Webbläsarinloggning, kopierade engångskoder och statusmeddelanden som bara består av text är oförenliga med en obevakad runner. Dockup stöder det icke-interaktiva flödet via DOCKUP_TOKEN, strukturerad JSON och deploy-kommandon som returnerar en riktig felkod.

Den här guiden bygger ett pipelinekontrakt som Claude Code, Codex, ett shell-skript eller ett konventionellt CI-jobb kan använda. Samma regler gäller: injicera tokenen vid körning, verifiera identiteten, hitta eller ange det exakta målet, vänta på ett slutgiltigt resultat och bevara diagnostik vid fel.

Varför behöver AI-agenters CI/CD icke-interaktiv autentisering?

Interaktiv dockup login öppnar en autentiseringssida och väntar på en token. Det passar på en utvecklares arbetsstation, men en containeriserad runner kanske saknar webbläsare, beständig hemkatalog och någon som kan klistra in något.

DOCKUP_TOKEN löser den gränsen:

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

Miljövariabeln har företräde framför ~/.dockup/config.json. whoami rapporterar tokenSource, så pipelinen kan bevisa att den använder den avsedda injicerade autentiseringsuppgiften i stället för en gammal konfigurationsfil som lämnats kvar på en self-hosted runner.

Kör inte dockup login -t "$DOCKUP_TOKEN" i CI om det inte finns ett specifikt skäl att spara en konfigurationsfil. Om miljövariabeln anges direkt begränsas autentiseringsuppgiften till processen och den skrivs inte till runnerns hemkatalog.

Pipelinen får aldrig skriva ut tokenen. Inaktivera shell tracing runt kommandon som innehåller hemligheter, undvik att skriva ut hela miljön och använd CI-plattformens funktion för maskerade hemligheter.

Hur ska DOCKUP_TOKEN lagras och begränsas?

Lagra tokenen som en krypterad repository-, miljö- eller organisationshemlighet. Föredra en hemlighet på miljönivå för produktion, eftersom den kan kombineras med begränsningar för brancher och manuella godkännanden som tillhandahålls av CI-plattformen.

En säker tokenpolicy besvarar fem frågor:

Fråga	Rekommenderat svar
Var lagras tokenen?	CI-plattformens krypterade hemlighetslagring
När exponeras den?	Endast i distributionsjobbet
Vilka brancher får använda den?	Skyddade produktionsbrancher
Vem får ändra workflowet?	Granskade underhållsansvariga
Hur granskas användningen?	Dockups auditlogg samt CI-jobbhistorik

Dockup stöder även API-nycklar med behörigheter. Lista tillgängliga behörighetsnamn innan du skapar en snävt begränsad nyckel:

dockup keys permissions --json

Välj endast exakta behörighetsnamn som returneras av plattformen och skapa sedan nyckeln genom arbetsflödet för API-nycklar med behörigheter. Fånga den genererade nyckeln på ett säkert sätt när den skapas och lagra den omedelbart. Inkludera den inte i ett ärende, en pull request eller en agentsession. Ett distributionsjobb ska inte få bred kontoadministration bara för att en utvecklartoken redan har den behörigheten.

Artikeln Skyddsräcken för AI-agenter i produktion beskriver en bredare behörighetstrappa.

Hur bygger man en distributionspipeline som väntar på sanningen?

Installera CLI:t i jobbet, verifiera identiteten och distribuera sedan 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 viktiga är inte vilken CI-leverantör som används, utan kommandokontraktet. dockup deploy ... --wait --json avslutas med 0 endast när distributionen når statusen lyckad. Standardtimeouten är 900 sekunder. En misslyckad build returnerar en exitkod som inte är noll tillsammans med deploy_failed; en operation som inte nått terminalstatus när timeouten löper ut returnerar deploy_timeout.

Eftersom processen avslutas med en exitkod som inte är noll markerar runnern steget och jobbet som misslyckade. Ingen loggparsning krävs.

För ett länkat repository som ska pusha sin aktuella branch och distribuera väntar dockup push --json som standard. I ett CI-jobb som redan har tagit emot en Git push-händelse är ett explicit dockup deploy <target> ofta tydligare, eftersom det undviker att runnern pushar.

Hur ska en pipeline samla in loggar och felkoder?

Bevara JSON-resultatet från distributionen som ett artifact eller jobbutdata, men se till att en omdirigering inte döljer exitstatusen. Ett shell-mönster kan fånga båda:

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 avslutas med den ursprungliga deploy-statusen. Buildloggar samlas endast in efter ett fel. Runtime-loggar bör samlas in när imagen byggdes men applikationen senare kraschar:

dockup logs production/api --json

För direkt insyn i en pågående build skickar follow-läget ut NDJSON:

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

Strömmen avslutas när distributionen gör det, och ett fel förblir ett processresultat som inte är noll. Den detaljerade diagnostiksekvensen beskrivs i felsökning av build- och runtime-loggar.

En pipeline bör förgrena sig baserat på koder, inte på textfragment i meddelanden:

Kod	Pipelinerespons
not_logged_in	Misslyckas omedelbart; injiceringen av hemligheten fungerar inte
no_target	Misslyckas; målkonfigurationen är ogiltig
deploy_trigger_failed	Misslyckas innan väntan; inspektera det returnerade felet
deploy_failed	Ladda upp buildloggar och markera jobbet som misslyckat
deploy_timeout	Markera som osäkert; kontrollera status innan du försöker igen
needs_confirm	Stoppa; ett destruktivt steg saknar godkännande

Hur kan en agent delta utan att försvaga CI-säkerheten?

En agent kan förbereda kod, uppdatera ett granskat workflow, tolka JSON och sammanfatta en misslyckad build. Den behöver inte obegränsad åtkomst till produktionstokenen under varje kodningssession.

Separera rollerna:

1. Utvecklingsagent: redigerar kod och kör tester lokalt.
2. Granskningsprocess: validerar ändringar i distributionskonfigurationen.
3. CI-runner: tar emot DOCKUP_TOKEN först efter den godkända triggern.
4. Dockup: kör distributionen och registrerar audit-händelser.
5. Agent eller operatör: tolkar resultatet och föreslår återställning.

Detta förhindrar att en prompt injection i en orelaterad uppgift får tillgång till produktionsautentiseringsuppgifter. Agenten kan fortfarande förstå pipelinen eftersom kommandona och den förväntade JSON-strukturen finns i repositoryt, medan själva hemligheten förblir utanför repositoryt.

För distributioner som körs direkt av en agent injicerar du tokenen i den specifika Claude Code- eller Codex-processen och installerar det medföljande skill-paketet:

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

Skill-paketet instruerar båda agenterna att använda icke-interaktiv autentisering, JSON, exakt måldetektering, väntan på terminalstatus och bekräftelsesteg.

Vad gör AI-agenters CI/CD repeterbar och granskningsbar?

Repeterbarhet börjar med ett explicit mål. Lagra production/api som en skyddad pipelinevariabel eller en granskad literal, inte som ett namn som agenten härleder vid körning. Validera kontot innan den första skrivoperationen.

Idempotens kräver olika hantering beroende på operation:

• Att läsa identitet, status, loggar och historik är säkert att upprepa.
• När en tjänst skapas måste målidentifiering göras först, så att nya försök inte skapar en dubblett.
• En ny distribution skapar ytterligare en produktionshändelse och bör registreras.
• Miljöändringar är mutationer och kräver en ny distribution.
• Destruktion och rensning får inte vara automatiska mål för nya försök.

Efter distributionen samlar du in bevis från plattformen:

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

Uptime mäts varje minut och omfattar genomsnittlig svarstid samt p95-svarstid. Audit-utdata kopplar CI-mutationen till senare granskning. CPU-, RAM- och diskanvändning mäts också varje minut mot kontots saldo. Den rekommenderade Pro-planen kostar 20 dollar per månad och inkluderar 20 dollar i användningskredit.

En komplett pipelinepost innehåller Git-committen, Dockup-målet, distributions-ID:t, start- och sluttidsstämplar, exitkod, terminalstatus och länkar till build-artifacts. Det gör en AI-agenters CI/CD-release reproducerbar även när den ursprungliga agentsessionen är borta.

Dockup CLI-referensen ska betraktas som kommandokällan. Följ Från Git-repository till produktion om du behöver skapa ett repository innan CI aktiveras.

Kontrollera samtidighet och befordran mellan miljöer

Två lyckade pipelines kan ändå skapa en osäker release om de körs samtidigt mot samma mål. Använd CI-plattformens samtidighetskontroller så att ett nyare produktionsjobb antingen väntar på eller medvetet ersätter ett äldre. Dockup rapporterar sanningsenligt varje distribution, men repositoryts workflow måste avgöra i vilken ordning överlappande commits ska hanteras.

Befordra samma granskade commit mellan miljöer i stället för att bygga om ett lokalt tillstånd som inte spåras. Ett staging-jobb kan distribuera staging/api, köra applikationskontroller och därefter släppa igenom ett skyddat produktionsjobb som distribuerar production/api. Håll tokenar och mål separerade så att en staging-agent inte råkar passera gränsen.

Definiera en policy för timeout-försök

deploy_timeout betyder varken att operationen misslyckades eller lyckades. Det betyder att operationen fortfarande kördes när väntan på 900 sekunder tog slut. Kontrollera följande innan du försöker igen:

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

Om den ursprungliga distributionen senare nådde statusen lyckad skulle ett blint nytt försök skapa ytterligare en release. Om den misslyckades ska du samla in buildloggen. Om den fortfarande inte nått terminalstatus och builden faktiskt är långvarig ska du observera den igen med en större, dokumenterad timeout i stället för att skapa en andra distribution.

Den här distinktionen hindrar AI-agenters CI/CD från att omvandla osäkerhet kring nätverk eller timing till dubbla produktionsändringar.

Registrera distributionens identitet

Ta med Dockup-kontots identitet, målet, commitens SHA, distributions-ID:t och terminalstatusen i CI-sammanfattningen. Denna lilla post gör att en senare operatör kan koppla pipelinekörningen till Dockups audit-händelser utan att tokenen exponeras.

Ta workflowet i produktion

Installera CLI:t i runnern, verifiera den injicerade identiteten och låt terminalens exitstatus – inte en loggrad som ser lyckad ut – vara pipelinens grind.

npm install -g dockup-cli
dockup skill install

Det första kommandot installerar CLI:t. Det andra installerar det matchande Dockup-skill-paketet för Claude Code och Codex. Kom igång gratis på app.dockup.ai.

Vanliga frågor

Vad är DOCKUP_TOKEN?

DOCKUP_TOKEN är den miljöbaserade autentiseringsvägen för Dockup CLI-sessioner som inte kan slutföra en interaktiv webbläsarinloggning, inklusive CI-runners, containrar och AI-agenter.

Åsidosätter DOCKUP_TOKEN en lokal Dockup-konfigurationsfil?

Ja. Miljöt tokenen har företräde, och dockup whoami --json rapporterar den aktiva tokenkällan.

Hur vet ett CI-jobb att en Dockup-distribution misslyckades?

Kör dockup deploy med --wait och --json. Kommandot avslutas med en exitkod som inte är noll och en strukturerad felkod när distributionen misslyckas eller når timeout.

Bör ett CI-workflow skriva ut distributionstokenen för felsökning?

Nej. Behåll den i CI-plattformens hemlighetslagring, undvik shell tracing och dumpning av miljön och exponera den endast för distributionssteget.

Kan Claude Code eller Codex använda samma CI-autentiseringsväg?

Ja. Båda kan använda DOCKUP_TOKEN och det medföljande Dockup-skill-paketet, som lär ut samma regler för JSON, måldetektering, väntan och bekräftelse.