DOCKUP_TOKEN ile AI Agent CI/CD

AI agent CI/CD, ancak kimlik doğrulama ve dağıtım, terminal başında bir kişi olmadan doğru şekilde çalıştığında başarılı olur. Tarayıcı üzerinden login, elle kopyalanan tek kullanımlık kodlar ve yalnızca metinle verilen durum mesajları, gözetimsiz bir runner ile uyumlu değildir. Dockup, DOCKUP_TOKEN, yapılandırılmış JSON ve gerçek bir hata çıkış kodu döndüren deploy komutlarıyla etkileşimsiz çalışma akışını destekler.

Bu kılavuzda Claude Code, Codex, bir shell script'i veya geleneksel bir CI job'ının kullanabileceği bir pipeline sözleşmesi oluşturuyoruz. Aynı kurallar geçerlidir: token'ı çalışma zamanında enjekte edin, kimliği doğrulayın, tam hedefi keşfedin veya açıkça belirtin, terminal sonucunu bekleyin ve hata durumunda tanılama bilgilerini koruyun.

AI agent CI/CD neden etkileşimsiz kimlik doğrulamaya ihtiyaç duyar?

Etkileşimli dockup login, bir kimlik doğrulama sayfası açar ve token bekler. Bu, geliştirici workstation'ı için uygundur; ancak container'laştırılmış bir runner'ın tarayıcısı, kalıcı bir home directory'si veya herhangi bir şeyi yapıştırabilecek bir kullanıcısı olmayabilir.

DOCKUP_TOKEN bu sınırı ortadan kaldırır:

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

Environment variable, ~/.dockup/config.json dosyasına göre önceliklidir. whoami, tokenSource bilgisini raporlar; böylece pipeline, self-hosted runner'da kalmış eski bir config dosyası yerine amaçlanan enjekte edilmiş credential'ı kullandığını kanıtlayabilir.

Özel bir config dosyasını kalıcı olarak saklamak için belirli bir nedeniniz yoksa CI içinde dockup login -t "$DOCKUP_TOKEN" çalıştırmayın. Environment variable'ı doğrudan sağlamak, credential'ın yalnızca ilgili process kapsamında kalmasını sağlar ve runner'ın home directory'sine yazılmasını önler.

Pipeline token'ı hiçbir zaman ekrana yazdırmamalıdır. Secret içeren komutların çevresinde shell tracing'i devre dışı bırakın, tüm environment'ın yazdırılmasından kaçının ve CI platformunun masked secret özelliğini kullanın.

DOCKUP_TOKEN nasıl saklanmalı ve kapsamı nasıl belirlenmeli?

Token'ı şifrelenmiş repository, environment veya organization secret olarak saklayın. Production için environment-level secret kullanmak daha güvenlidir; çünkü bu secret, CI platformunun sunduğu branch kısıtlamaları ve manuel onaylarla birlikte kullanılabilir.

Güvenli bir token politikası şu beş soruyu yanıtlamalıdır:

Soru	Önerilen yanıt
Token nerede saklanıyor?	CI şifreli secret store'u
Ne zaman açığa çıkarılıyor?	Yalnızca deployment job'ında
Hangi branch'ler kullanabilir?	Korunan production branch'leri
Workflow'u kim değiştirebilir?	Değişiklikleri incelenmiş maintainer'lar
Kullanım nasıl inceleniyor?	Dockup audit log'u ve CI job geçmişi

Dockup, permission tanımlı API key'leri de destekler. Dar kapsamlı bir key oluşturmadan önce kullanılabilir permission adlarını listeleyin:

dockup keys permissions --json

Yalnızca platform tarafından döndürülen tam permission adlarını seçin, ardından key'i permission tanımlı API-key workflow'u üzerinden oluşturun. Oluşturma sırasında üretilen key'i güvenli biçimde alın ve hemen saklayın; bunu bir issue'ya, pull request'e veya agent transcript'ine eklemeyin. Bir deployment job'ı, geliştirici token'ında zaten geniş hesap yönetimi yetkileri var diye bu yetkileri devralmamalıdır.

AI agent production guardrails makalesinde daha kapsamlı bir permission kademesi açıklanmaktadır.

Gerçeği bekleyen bir deployment pipeline'ı nasıl oluşturulur?

Job içinde CLI'ı kurun, kimliği doğrulayın, ardından --wait ile deploy edin:

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

Önemli olan CI vendor'ı değil, komut sözleşmesidir. dockup deploy ... --wait --json, yalnızca deployment başarıya ulaştığında 0 çıkış koduyla sonlanır. Varsayılan timeout 900 saniyedir. Başarısız bir build, deploy_failed ile birlikte non-zero çıkış kodu döndürür; timeout sırasında terminal duruma ulaşmamış bir operation ise deploy_timeout döndürür.

Process non-zero ile sonlandığı için runner step'i ve job'ı failed olarak işaretler. Log scraping yapmaya gerek kalmaz.

Mevcut branch'ini push edip deploy etmesi gereken bağlı bir repository için dockup push --json, varsayılan olarak bekler. Git push event'i almış bir CI job'ında açıkça dockup deploy <target> kullanmak genellikle daha anlaşılırdır; çünkü runner'dan push yapılmasını önler.

Pipeline log'ları ve hata kodlarını nasıl yakalamalı?

JSON deployment sonucunu artifact veya job output olarak koruyun; ancak bir redirection'ın exit status'u gizlemesine izin vermeyin. Bir shell pattern'i her ikisini de yakalayabilir:

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, orijinal deploy status'u ile sonlanır. Build log'ları yalnızca hata sonrasında toplanır. Image build edilmiş ancak application daha sonra crash olmuşsa runtime log'ları toplanmalıdır:

dockup logs production/api --json

Canlı build görünürlüğü için follow mode NDJSON üretir:

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

Stream, deployment sona erdiğinde sona erer ve hata durumunda process sonucu non-zero olmaya devam eder. Ayrıntılı tanılama sırası build ve runtime log debugging makalesinde ele alınmaktadır.

Pipeline, message fragment'larına değil code'lara göre dallanmalıdır:

Code	Pipeline yanıtı
not_logged_in	Hemen fail edin; secret injection bozuk
no_target	Fail edin; target configuration geçersiz
deploy_trigger_failed	Beklemeden önce fail edin; döndürülen hatayı inceleyin
deploy_failed	Build log'larını yükleyin ve fail edin
deploy_timeout	Belirsiz olarak işaretleyin; retry'dan önce status'u inceleyin
needs_confirm	Durdurun; destructive step onay gerektiriyor

Bir agent, CI güvenliğini zayıflatmadan nasıl sürece katılabilir?

Bir agent kod hazırlayabilir, incelenmiş bir workflow'u güncelleyebilir, JSON'u yorumlayabilir ve başarısız bir build'i özetleyebilir. Her coding session'da production token'ına sınırsız erişmesi gerekmez.

Rolleri ayırın:

1. Development agent: Kod ve testleri local olarak düzenler.
2. Review process: Deployment configuration değişikliklerini doğrular.
3. CI runner: DOCKUP_TOKEN'ı yalnızca onaylanmış trigger sonrasında alır.
4. Dockup: Deployment'ı gerçekleştirir ve audit event'lerini kaydeder.
5. Agent veya operator: Sonucu yorumlar ve recovery önerir.

Bu düzenleme, ilgisiz bir görevdeki prompt injection'ın production credential'larını ele geçirmesini önler. Komutlar ve beklenen JSON repository'ye commit edildiği için agent pipeline'ı anlayabilir; secret değeri ise repository dışında kalır.

Doğrudan agent tarafından çalıştırılan deployment'lar için token'ı ilgili Claude Code veya Codex process'ine enjekte edin ve bundled skill'i kurun:

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

Skill, her iki agent'a da etkileşimsiz kimlik doğrulama, JSON, tam hedef keşfi, terminal durumu bekleme ve confirmation gate'leri kullanmayı öğretir.

AI agent CI/CD'yi tekrarlanabilir ve denetlenebilir kılan nedir?

Tekrarlanabilirlik, açıkça belirtilmiş bir target ile başlar. production/api değerini agent'ın runtime'da türettiği bir ad olarak değil, korunan bir pipeline variable veya incelenmiş bir literal olarak saklayın. İlk write işleminden önce account'u doğrulayın.

Idempotency, operation türüne göre farklı bir yaklaşım gerektirir:

• Identity, status, logs ve history okumak güvenle tekrarlanabilir.
• Service oluşturma, retry'ların duplicate oluşturmaması için target discovery ile başlamalıdır.
• Yeniden deploy etmek yeni bir production event'i oluşturur ve kaydedilmelidir.
• Environment değişiklikleri mutation'dır ve redeploy gerektirir.
• Destruction ve pruning işlemleri otomatik retry hedefi olmamalıdır.

Deployment sonrasında platform kanıtlarını toplayın:

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

Uptime her dakika ölçülür ve average ile p95 response time değerlerini içerir. Audit output'u, CI mutation'ını sonraki incelemeyle ilişkilendirir. CPU, RAM ve disk tüketimi de account balance'a göre dakika bazında ölçülür; önerilen Pro planı aylık $20 karşılığında $20 kullanım kredisi sunar.

Eksiksiz bir pipeline kaydı Git commit'ini, Dockup target'ını, deployment ID'sini, başlangıç ve bitiş timestamp'lerini, exit code'u, terminal status'u ve build artifact'larına bağlantıları içerir. Bu sayede özgün agent session'ı artık mevcut olmasa bile bir AI agent CI/CD release'i yeniden üretilebilir.

Dockup CLI reference, komutlar için otorite olarak kabul edilmelidir. CI etkinleştirilmeden önce repository oluşturmak için Git repository to production kılavuzunu izleyin.

Concurrency'yi ve environment promotion'ı kontrol edin

Aynı target üzerinde eşzamanlı çalışan iki başarılı pipeline yine de güvenli olmayan bir release oluşturabilir. Daha yeni bir production job'ının eski job'ı beklemesini veya bilinçli olarak onun yerini almasını sağlamak için CI platformunun concurrency kontrollerini kullanın. Dockup her deployment'ı doğru şekilde raporlar; ancak çakışan commit'lerin hangi sırayla işleneceğine repository workflow'u karar vermelidir.

Takip edilmeyen local bir state'i yeniden build etmek yerine, aynı incelenmiş commit'i environment'lar arasında promote edin. Bir staging job'ı staging/api'ye deploy edebilir, application kontrollerini çalıştırabilir ve ardından korunan bir production job'ının production/api'ye deploy etmesine izin verebilir. Bir staging agent'ının yanlışlıkla sınırı aşmaması için token'ları ve target'ları birbirinden ayırın.

Timeout'lar için bir retry politikası tanımlayın

deploy_timeout, failure anlamına gelmez; success anlamına da gelmez. Bu, 900 saniyelik wait süresi sona erdiğinde operation'ın hâlâ çalıştığı anlamına gelir. Retry etmeden önce şunları inceleyin:

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

Özgün deployment daha sonra başarıya ulaştıysa, düşünmeden yapılacak bir retry başka bir release oluşturur. Başarısız olduysa build log'unu toplayın. Terminal olmayan durumda kalmaya devam ediyor ve build gerçekten uzunsa ikinci bir deployment oluşturmak yerine, belgelenmiş daha uzun bir timeout ile gözlemi yeniden çalıştırın.

Bu ayrım, AI agent CI/CD'nin network veya zamanlama belirsizliğini duplicate production değişikliklerine dönüştürmesini önler.

Deployment kimliğini kaydedin

CI summary'ye Dockup account identity'sini, target'ı, commit SHA'yı, deployment ID'sini ve terminal status'u ekleyin. Bu küçük kayıt, token'ı açığa çıkarmadan daha sonra pipeline run'ını Dockup audit event'leriyle ilişkilendirmenizi sağlar.

Workflow'u production'a alın

CLI'ı runner'a kurun, enjekte edilen identity'yi doğrulayın ve pipeline gate'i olarak başarı izlenimi veren bir log satırı yerine terminal exit status'unu kullanın.

npm install -g dockup-cli
dockup skill install

İlk komut CLI'ı kurar. İkinci komut, Claude Code ve Codex için eşleşen Dockup skill'ini kurar. app.dockup.ai adresinde ücretsiz başlayın.

SSS

DOCKUP_TOKEN nedir?

DOCKUP_TOKEN, CI runner'ları, container'lar ve AI agent'lar da dahil olmak üzere etkileşimli browser login'ini tamamlayamayan Dockup CLI session'ları için environment tabanlı kimlik doğrulama yoludur.

DOCKUP_TOKEN local bir Dockup config dosyasını geçersiz kılar mı?

Evet. Environment token'ı önceliklidir ve dockup whoami --json etkin token source'unu raporlar.

Bir CI job'ı Dockup deployment'ının başarısız olduğunu nasıl anlar?

--wait ve --json ile dockup deploy çalıştırın. Deploy başarısız olduğunda veya timeout'a uğradığında komut, yapılandırılmış bir failure code ile non-zero olarak sonlanır.

Bir CI workflow'u debugging için deployment token'ını yazdırmalı mı?

Hayır. Token'ı CI secret store'unda tutun, shell tracing'den ve environment dump'larından kaçının ve token'ı yalnızca deployment step'ine açın.

Claude Code veya Codex aynı CI authentication path'ini kullanabilir mi?

Evet. İkisi de DOCKUP_TOKEN'ı ve aynı JSON, target discovery, wait ve confirmation kurallarını öğreten bundled Dockup skill'ini kullanabilir.