AI-agentin CI/CD DOCKUP_TOKENilla

AI-agentin CI/CD onnistuu vain, kun tunnistautuminen ja käyttöönotto toimivat oikein ilman päätteen ääressä olevaa henkilöä. Selainkirjautuminen, käsin kopioitavat kertakäyttökoodit ja pelkät tekstimuotoiset tilaviestit eivät sovi valvomattomaan runneriin. Dockup tukee ei-interaktiivista toimintatapaa DOCKUP_TOKEN-muuttujan, rakenteisen JSON-muodon ja käyttöönottokomentojen avulla. Komennot palauttavat todellisen virheen ilmaisevan exit-koodin.

Tässä oppaassa rakennetaan pipeline-sopimus, jota voivat käyttää Claude Code, Codex, shell-skripti tai perinteinen CI-työ. Samat säännöt pätevät aina: syötä token ajonaikaisesti, varmista identiteetti, selvitä tai määritä täsmällinen kohde, odota päätetilaa ja säilytä virhediagnostiikka.

Miksi AI-agentin CI/CD tarvitsee ei-interaktiivisen tunnistautumisen?

Interaktiivinen dockup login avaa tunnistautumissivun ja odottaa tokenia. Tämä sopii kehittäjän työasemalle, mutta containeroitu runneri ei välttämättä tarjoa selainta tai pysyvää kotihakemistoa, eikä paikalla ole henkilöä syöttämässä mitään.

DOCKUP_TOKEN ratkaisee tämän rajapinnan:

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

Ympäristömuuttuja ohittaa tiedoston ~/.dockup/config.json. whoami ilmoittaa kentän tokenSource, joten pipeline voi todistaa käyttävänsä tarkoituksella syötettyä tunnistetietoa vanhan, itse ylläpidetylle runnerille jääneen asetustiedoston sijaan.

Älä suorita CI:ssä komentoa dockup login -t "$DOCKUP_TOKEN", ellei asetustiedoston säilyttämiseen ole erityistä syytä. Ympäristömuuttujan suora käyttö rajaa tunnistetiedon prosessiin ja estää sen kirjoittamisen runnerin kotihakemistoon.

Pipeline ei saa koskaan tulostaa tokenia. Poista shellin tracing salaisuuksia sisältävien komentojen ajaksi, vältä koko ympäristön tulostamista ja käytä CI-alustan masked secret -toimintoa.

Miten DOCKUP_TOKEN kannattaa tallentaa ja rajata?

Tallenna token salattuun repository-, ympäristö- tai organisaatiokohtaiseen secret storeen. Tuotannossa kannattaa suosia ympäristökohtaista secretia, koska siihen voi yhdistää branch-rajoitukset ja CI-alustan tarjoamat manuaaliset hyväksynnät.

Turvallinen token-käytäntö vastaa viiteen kysymykseen:

Kysymys	Suositeltu vastaus
Missä token säilytetään?	CI:n salatussa secret storessa
Milloin se tuodaan näkyviin?	Vain deployment-jobin aikana
Mitkä branchit voivat käyttää sitä?	Suojatut production-branchit
Kuka voi muuttaa workflow’ta?	Tarkistetut ylläpitäjät
Miten käyttö tarkistetaan?	Dockupin audit log sekä CI-jobin historia

Dockup tukee myös oikeuksilla rajattuja API-avaimia. Listaa käytettävissä olevat oikeuksien nimet ennen suppeasti rajatun avaimen luomista:

dockup keys permissions --json

Valitse vain alustan palauttamat täsmälliset oikeuksien nimet ja luo avain sitten oikeuksilla rajatun API-avaimen työnkulun kautta. Ota luotu avain turvallisesti talteen luonnin aikana ja tallenna se heti. Älä sisällytä sitä issueen, pull requestiin tai agentin transkriptiin. Deployment-jobin ei pidä periä laajoja tilin hallintaoikeuksia vain siksi, että kehittäjän tokenilla on ne jo käytössä.

AI-agenttien tuotantokäytön suojakaiteet -artikkelissa kuvataan laajempi oikeusmalli.

Miten rakennetaan totuutta odottava deployment-pipeline?

Asenna CLI jobissa, varmista identiteetti ja tee deployment --wait-valitsimella:

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

Oleellista ei ole CI-toimittaja vaan komentojen välinen sopimus. dockup deploy ... --wait --json palauttaa 0 vain, kun deployment saavuttaa onnistuneen tilan. Oletusaikakatkaisu on 900 sekuntia. Epäonnistunut build palauttaa nollasta poikkeavan exit-koodin ja koodin deploy_failed; aikakatkaisun hetkellä päätetilaan päätymätön operaatio palauttaa koodin deploy_timeout.

Koska prosessi päättyy nollasta poikkeavasti, runneri merkitsee stepin ja jobin epäonnistuneiksi. Lokien erillistä läpikäyntiä ei tarvita.

Jos linkitetyn repositoryn pitää pushata nykyinen branch ja tehdä deployment, dockup push --json odottaa oletusarvoisesti valmistumista. CI-jobissa, joka on jo vastaanottanut Git-push-tapahtuman, eksplisiittinen dockup deploy <target> on usein selkeämpi, koska se estää runneria tekemästä pushia.

Miten pipeline kerää lokit ja virhekoodit?

Säilytä JSON-muotoinen deployment-tulos artefaktina tai jobin outputina, mutta varmista, ettei uudelleenohjaus peitä exit-statusta. Shell-kuvio voi kerätä molemmat:

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 päättyy alkuperäiseen deployment-statukseen. Build-lokit kerätään vain epäonnistumisen jälkeen. Runtime-lokit kannattaa kerätä silloin, kun image rakentui mutta sovellus kaatuu myöhemmin:

dockup logs production/api --json

Reaaliaikaista build-näkyvyyttä varten follow-tila tuottaa NDJSON:ää:

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

Virta päättyy deploymentin päättyessä, ja virhe säilyy nollasta poikkeavana prosessituloksena. Yksityiskohtainen diagnostiikkajärjestys kuvataan artikkelissa build- ja runtime-lokien vianmääritys.

Pipelinen kannattaa haarautua koodien, ei viestikatkelmien, perusteella:

Koodi	Pipelinen toiminta
not_logged_in	Keskeytä heti; secretin syöttäminen ei toimi
no_target	Keskeytä; kohteen määritys on virheellinen
deploy_trigger_failed	Keskeytä ennen odottamista; tarkista palautettu virhe
deploy_failed	Lataa build-lokit ja ilmoita epäonnistumisesta
deploy_timeout	Merkitse tila epävarmaksi; tarkista status ennen uutta yritystä
needs_confirm	Keskeytä; tuhoava vaihe puuttuu hyväksynnästä

Miten agentti voi osallistua heikentämättä CI:n tietoturvaa?

Agentti voi valmistella koodia, päivittää tarkistetun workflow’n, tulkita JSONia ja tehdä yhteenvedon epäonnistuneesta buildistä. Sillä ei tarvitse olla rajoittamatonta pääsyä production-tokeniin jokaisessa koodaussessiossa.

Erota roolit:

1. Kehitysagentti: muokkaa koodia ja testejä paikallisesti.
2. Review-prosessi: tarkistaa deployment-määritysten muutokset.
3. CI-runneri: saa DOCKUP_TOKEN-muuttujan vasta hyväksytyn triggerin jälkeen.
4. Dockup: suorittaa deploymentin ja tallentaa audit-tapahtumat.
5. Agentti tai operaattori: tulkitsee tuloksen ja ehdottaa palautustoimia.

Tämä rakenne estää toisessa tehtävässä tapahtuvaa prompt injection -hyökkäystä saamasta tuotannon tunnistetietoja. Agentti pystyy silti ymmärtämään pipelinen, koska komennot ja odotettu JSON on tallennettu repositoryyn, kun taas salaisuuden arvo pysyy sen ulkopuolella.

Jos agentti tekee deploymentit suoraan, syötä token tietyn Claude Code- tai Codex-prosessin käyttöön ja asenna mukana toimitettava skill:

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

Skill ohjeistaa molempia agentteja käyttämään ei-interaktiivista tunnistautumista, JSONia, täsmällistä kohteen selvitystä, päätetilaan asti odottamista ja vahvistusportteja.

Mikä tekee AI-agentin CI/CD:stä toistettavaa ja auditoitavaa?

Toistettavuus alkaa eksplisiittisestä kohteesta. Tallenna production/api suojatuksi pipeline-muuttujaksi tai tarkistetuksi literal-arvoksi sen sijaan, että agentti johtaisi nimen ajon aikana. Varmista tili ennen ensimmäistä kirjoittavaa operaatiota.

Idempotenssi edellyttää eri operaatioilta erilaista käsittelyä:

• Identiteetin, statuksen, lokien ja historian lukeminen voidaan toistaa turvallisesti.
• Servicen luomisen pitää alkaa kohteen selvittämisellä, jotta retryt eivät luo duplikaattia.
• Uusi deployment luo uuden production-tapahtuman, joka pitää kirjata.
• Ympäristömuutokset ovat mutaatioita ja edellyttävät uutta deploymentia.
• Tuhoamista ja pruningia ei pidä määrittää automaattisesti uudelleen yritettäviksi operaatioiksi.

Kerää deploymentin jälkeen alustalta seuraavat tiedot:

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

Uptime mitataan minuutin välein, ja se sisältää keskimääräisen sekä p95-vasteajan. Audit-tuloste yhdistää CI:n tekemän mutaation myöhempään tarkasteluun. Myös CPU-, RAM- ja levytilan kulutus mitataan minuutin välein suhteessa tilin saldoon; suositeltu Pro-plan maksaa 20 dollaria kuukaudessa ja sisältää 20 dollarin usage creditin.

Täydellinen pipeline-tietue sisältää Git commitin, Dockup-kohteen, deployment ID:n, aloitus- ja lopetusajat, exit-koodin, päätetilan sekä linkit build-artefakteihin. Näin AI-agentin CI/CD-julkaisu on toistettavissa, vaikka alkuperäinen agentsessio olisi jo päättynyt.

Dockup CLI -referenssiä tulee pitää komentojen auktoritatiivisena lähteenä. Jos repository luodaan ennen CI:n käyttöönottoa, seuraa ohjetta Git-repositorysta tuotantoon.

Hallitse samanaikaisuutta ja ympäristöjen välistä promootiota

Kaksi onnistunutta pipelinea voi silti tuottaa turvattoman julkaisun, jos ne suoritetaan samanaikaisesti samaan kohteeseen. Käytä CI-alustan concurrency-asetuksia, jotta uudempi production-job joko odottaa vanhempaa jobia tai korvaa sen tarkoituksella. Dockup raportoi totuudenmukaisesti jokaisen deploymentin, mutta repositoryn workflow’n on päätettävä, missä järjestyksessä päällekkäiset commitit käsitellään.

Promotoi sama tarkistettu commit ympäristöstä toiseen sen sijaan, että rakentaisit seuraavan ympäristön seuraamattomasta paikallisesta tilasta. Staging-job voi tehdä deploymentin kohteeseen staging/api, suorittaa sovellustarkistukset ja antaa sitten suojatun production-jobin tehdä deploymentin kohteeseen production/api. Pidä tokenit ja kohteet erillään, jotta staging-agentti ei voi vahingossa ylittää ympäristörajaa.

Määritä aikakatkaisujen retry-käytäntö

deploy_timeout ei tarkoita epäonnistumista eikä onnistumista. Se tarkoittaa, että operaatio oli edelleen käynnissä 900 sekunnin odotusajan päättyessä. Tarkista ennen uutta yritystä:

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

Jos alkuperäinen deployment saavuttaa myöhemmin onnistuneen tilan, sokkona tehty retry loisi uuden julkaisun. Jos se epäonnistui, kerää build-loki. Jos tila ei edelleenkään ole päätetila ja build on aidosti pitkäkestoinen, jatka tilanteen tarkkailua dokumentoidulla pidemmällä aikakatkaisulla sen sijaan, että loisit toisen deploymentin.

Tämä ero estää AI-agentin CI/CD:tä muuttamasta verkko- tai ajoitusepävarmuutta päällekkäisiksi tuotantomuutoksiksi.

Tallenna deploymentin identiteetti

Sisällytä CI-yhteenvetoon Dockup-tilin identiteetti, kohde, commit SHA, deployment ID ja päätetila. Tämän pienen tietueen avulla myöhempi operaattori voi yhdistää pipeline-ajon Dockupin audit-tapahtumiin ilman tokenin paljastamista.

Vie workflow tuotantoon

Asenna CLI runneriin, varmista syötetyn identiteetin toiminta ja tee päätteen exit-statuksesta – ei onnistumiselta näyttävästä lokirivistä – pipelinen portinvartija.

npm install -g dockup-cli
dockup skill install

Ensimmäinen komento asentaa CLI:n. Toinen asentaa Claude Coden ja Codexin kanssa yhteensopivan Dockup skillin. Aloita maksutta osoitteessa app.dockup.ai.

UKK

Mikä on DOCKUP_TOKEN?

DOCKUP_TOKEN on ympäristömuuttujaan perustuva tunnistautumistapa Dockup CLI -sessioille, jotka eivät pysty suorittamaan interaktiivista selainkirjautumista. Tällaisia ovat esimerkiksi CI-runnerit, containerit ja AI-agentit.

Ohittaako DOCKUP_TOKEN paikallisen Dockup-asetustiedoston?

Kyllä. Ympäristötokenilla on etusija, ja dockup whoami --json ilmoittaa käytössä olevan token-lähteen.

Mistä CI-job tietää, että Dockup-deployment epäonnistui?

Suorita dockup deploy valitsimilla --wait ja --json. Komento päättyy nollasta poikkeavasti ja palauttaa rakenteisen virhekoodin, jos deployment epäonnistuu tai aikakatkaistaan.

Pitäisikö CI-workflown tulostaa deployment-token vianmääritystä varten?

Ei. Säilytä se CI:n secret storessa, vältä shellin tracingia ja ympäristön tulostamista ja anna se vain deployment-stepin käyttöön.

Voivatko Claude Code tai Codex käyttää samaa CI-tunnistautumistapaa?

Kyllä. Molemmat voivat käyttää DOCKUP_TOKENia ja mukana toimitettavaa Dockup skilliä, joka opettaa samat JSON-, kohteen selvitys-, odotus- ja vahvistussäännöt.