CI/CD за AI агенти с DOCKUP_TOKEN

CI/CD за AI агенти работи надеждно само когато автентикацията и deployment-ът се изпълняват коректно без човек пред терминала. Login през браузър, копиране на еднократни кодове и статуси само в текстов вид са несъвместими с runner, който работи без надзор. Dockup поддържа неинтерактивен сценарий чрез DOCKUP_TOKEN, структуриран JSON и deploy команди, които връщат реален failure exit code.

Това ръководство изгражда договор за pipeline, който може да се използва от Claude Code, Codex, shell script или стандартен CI job. Правилата са едни и същи: инжектирайте token-а по време на изпълнение, проверете identity, открийте или задайте точния target, изчакайте terminal result и запазете diagnostic информацията при failure.

Защо CI/CD за AI агенти се нуждае от неинтерактивна автентикация?

Интерактивният dockup login отваря страница за автентикация и изчаква token. Това е подходящо за developer workstation, но containerized runner-ът може да няма браузър, persistent home directory или човек, който да постави каквото и да било.

DOCKUP_TOKEN решава този проблем:

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

Environment variable-ът има приоритет пред ~/.dockup/config.json. whoami отчита tokenSource, така че pipeline-ът може да потвърди, че използва предвидената injected credential, а не стар config файл, останал в self-hosted runner.

Не изпълнявайте dockup login -t "$DOCKUP_TOKEN" в CI, освен ако няма конкретна причина да запазвате config файл. Директното подаване на environment variable ограничава credential-а до процеса и предотвратява записването му в home directory на runner-а.

Pipeline-ът никога не трябва да отпечатва token-а. Изключвайте shell tracing около команди, които обработват secrets, не отпечатвайте цялата environment информация и използвайте функцията на CI платформата за masked secrets.

Как трябва да се съхранява и ограничава DOCKUP_TOKEN?

Съхранявайте token-а като encrypted repository, environment или organization secret. За production предпочитайте environment-level secret, защото той може да се комбинира с ограничения за branch-ове и manual approvals, предоставени от CI платформата.

Сигурната token policy трябва да отговаря на пет въпроса:

Въпрос	Препоръчителен отговор
Къде се съхранява token-ът?	CI encrypted secret store
Кога се предоставя?	Само в deployment job-а
Кои branch-ове могат да го използват?	Защитени production branch-ове
Кой може да променя workflow-а?	Maintainer-и, преминали code review
Как се преглежда използването?	Dockup audit log плюс CI job history

Dockup поддържа и permissioned API keys. Изведете наличните имена на permissions, преди да създадете key с ограничен обхват:

dockup keys permissions --json

Изберете само точните имена на permissions, върнати от платформата, след което създайте key-а чрез workflow-а за permissioned API key. Запазете генерирания key сигурно още при създаването му и не го включвайте в issue, pull request или agent transcript; deployment job-ът не трябва да наследява широки административни права само защото developer token-ът вече ги притежава.

Статията AI agent production guardrails представя по-широка permission ladder.

Как се изгражда deployment pipeline, който изчаква реалния резултат?

Инсталирайте CLI в job-а, проверете identity и след това стартирайте deployment с --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

Важна не е CI vendor-ът, а договорът на командата. dockup deploy ... --wait --json завършва с 0 само когато deployment-ът достигне success. Default timeout-ът е 900 секунди. Неуспешен build връща non-zero exit code с deploy_failed, а non-terminal operation при изтичане на timeout-а връща deploy_timeout.

Тъй като процесът завършва с non-zero exit code, runner-ът маркира стъпката и job-а като failed. Не е необходимо извличане на информация чрез анализ на log-ове.

При linked repository, което трябва да push-не текущия branch и да deploy-не, dockup push --json изчаква по подразбиране. В CI job, който вече е получил Git push event, изричният dockup deploy <target> често е по-ясен, защото предотвратява push от runner-а.

Как pipeline-ът трябва да събира log-ове и error codes?

Запазете JSON резултата от deployment-а като artifact или job output, но не допускайте redirection да скрие exit status-а. Shell pattern може да събере и двете:

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-ът завършва с оригиналния deploy status. Build log-овете се събират само след failure. Runtime log-овете трябва да се събират, когато image-ът е изграден, но приложението по-късно crash-не:

dockup logs production/api --json

За live build visibility follow mode извежда NDJSON:

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

Stream-ът приключва, когато deployment-ът приключи, а failure-ът продължава да се отчита като non-zero process result. Подробната диагностична последователност е описана в debugging на build и runtime log-ове.

Pipeline-ът трябва да разклонява логиката според codes, а не според части от съобщения:

Code	Реакция на pipeline-а
not_logged_in	Незабавен failure; secret injection-ът е повреден
no_target	Failure; target конфигурацията е невалидна
deploy_trigger_failed	Failure преди изчакването; проверете върнатата грешка
deploy_failed	Качете build log-овете и маркирайте job-а като failed
deploy_timeout	Маркирайте резултата като несигурен; проверете status преди retry
needs_confirm	Спрете; destructive step-ът няма approval

Как агентът може да участва, без да отслабва сигурността на CI?

Агентът може да подготвя code, да обновява workflow, преминал review, да интерпретира JSON и да обобщава failed build. Не е необходимо да има неограничен достъп до production token-а във всяка coding session.

Разделете ролите:

1. Development agent: редактира code и изпълнява локални tests.
2. Review process: валидира промените по deployment конфигурацията.
3. CI runner: получава DOCKUP_TOKEN само след approved trigger.
4. Dockup: изпълнява deployment-а и записва audit events.
5. Agent или operator: интерпретира резултата и предлага recovery.

Тази организация предотвратява prompt injection в несвързана задача да получи production credentials. Агентът все пак може да разбере pipeline-а, защото командите и очакваният JSON са commit-нати, докато secret value остава извън repository-то.

При direct agent-run deployments инжектирайте token-а в конкретния Claude Code или Codex процес и инсталирайте bundled skill-а:

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

Skill-ът инструктира и двата агента да използват неинтерактивна автентикация, JSON, откриване на точния target, изчакване до terminal state и confirmation gates.

Какво прави CI/CD за AI агенти repeatable и auditable?

Repeatability започва с explicit target. Съхранявайте production/api като protected pipeline variable или проверен literal, а не като име, което агентът извежда по време на изпълнение. Валидирайте account-а преди първия write.

Idempotency изисква различен подход според operation-а:

• Четенето на identity, status, log-ове и history е безопасно за повторение.
• Създаването на service трябва да започва с target discovery, за да не създават retry-ите дубликат.
• Повторният deployment създава нов production event и трябва да бъде записан.
• Промените в environment са mutations и изискват redeploy.
• Destruction и pruning не трябва да бъдат автоматични retry targets.

След deployment съберете доказателства от платформата:

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

Uptime се измерва всяка минута и включва average и p95 response time. Audit output свързва CI mutation-а с последващия review. CPU, RAM и disk consumption също се измерват всяка минута спрямо баланса на account-а; препоръчителният Pro plan е $20 на месец с $20 usage credit.

Пълният pipeline record включва Git commit, Dockup target, deployment ID, начални и крайни timestamps, exit code, terminal status и линкове към build artifacts. Така един CI/CD release за AI агенти остава reproducible дори когато оригиналната agent session вече не съществува.

Dockup CLI reference трябва да се приема като authoritative източник за командите. За създаване на repository, преди да активирате CI, следвайте Git repository към production.

Контролирайте concurrency и promotion между environment-и

Два успешни pipeline-а все пак могат да създадат unsafe release, ако се изпълняват едновременно спрямо един и същ target. Използвайте concurrency controls на CI платформата, така че по-новият production job или да изчака стария, или съзнателно да го замени. Dockup ще отчете вярно всеки deployment, но repository workflow-ът трябва да определи реда на overlapping commits.

Promote-вайте един и същ reviewed commit между environment-ите, вместо да build-вате отново untracked local state. Staging job може да deploy-не staging/api, да изпълни application checks и след това да разреши на protected production job да deploy-не production/api. Поддържайте token-ите и target-ите различни, за да не може staging agent случайно да премине границата.

Дефинирайте retry policy за timeout-и

deploy_timeout не означава failure и не означава success. Означава, че operation-ът все още е изпълняван, когато 900-секундното изчакване е приключило. Преди retry проверете:

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

Ако оригиналният deployment по-късно е достигнал success, сляп retry би създал нов release. Ако е failed, съберете build log-а. Ако остава non-terminal и build-ът действително е дълъг, повторете наблюдението с по-голям, документиран timeout, вместо да създавате втори deployment.

Това разграничение не позволява на CI/CD за AI агенти да превръща мрежова или timing несигурност в дублирани production промени.

Записвайте deployment identity

Включвайте Dockup account identity, target, commit SHA, deployment ID и terminal status в CI summary. Този кратък запис позволява на последващ operator да свърже pipeline run-а с Dockup audit events, без да излага token-а.

Въведете workflow-а в production

Инсталирайте CLI в runner-а, проверете injected identity и превърнете terminal exit status-а — а не log line, който изглежда като success — в gate за pipeline-а.

npm install -g dockup-cli
dockup skill install

Първата команда инсталира CLI. Втората инсталира съответния Dockup skill за Claude Code и Codex. Започнете безплатно от app.dockup.ai.

Често задавани въпроси

Какво е DOCKUP_TOKEN?

DOCKUP_TOKEN е базираният на environment начин за автентикация на Dockup CLI sessions, които не могат да завършат интерактивен browser login, включително CI runner-и, containers и AI агенти.

DOCKUP_TOKEN има ли приоритет пред локален Dockup config файл?

Да. Environment token-ът има приоритет, а dockup whoami --json отчита активния token source.

Как CI job разбира, че Dockup deployment-ът е failed?

Изпълнете dockup deploy с --wait и --json. Командата завършва с non-zero exit code и structured failure code, когато deploy-ът failed-не или timeout-не.

Трябва ли CI workflow да отпечатва deployment token-а за debugging?

Не. Съхранявайте го в CI secret store, избягвайте shell tracing и environment dumps и го предоставяйте само на deployment step-а.

Могат ли Claude Code или Codex да използват същия CI authentication path?

Да. И двата могат да използват DOCKUP_TOKEN и bundled Dockup skill-а, който ги обучава на същите правила за JSON, target discovery, изчакване и confirmation.