Lewati ke konten utama
Versi: 1.0

Agent di CI/CD

CI adalah tempat paling aman untuk memulai automation penuh: setiap run terikat ke event repo yang jelas (PR dibuka, test gagal, issue dilabeli), semuanya ter-audit di log Actions, dan hasilnya selalu berupa komentar atau commit yang bisa di-review β€” bukan perubahan diam-diam di server.

Use case 1 β€” Auto-review setiap PR​

Cara resmi di ekosistem Claude adalah anthropics/claude-code-action β€” GitHub Action yang memberi Claude shell hidup di runner: bisa membaca file, menjalankan git, dan (bila diizinkan) push commit perbaikan. Ada dua mode yang dideteksi otomatis: tag mode (merespons mention @claude di PR/issue) dan agent mode (jalan headless dengan prompt di YAML). (docs)

Buat workflow review
.github/workflows/agent-review.yml
name: Agent Review
on:
pull_request:
types: [opened, synchronize]

jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
Review PR ini untuk bug correctness, masalah keamanan, dan
pelanggaran konvensi di AGENTS.md. Tulis temuan sebagai
komentar PR. JANGAN mengedit kode. Kalau tidak ada temuan
berarti, tulis satu komentar singkat "LGTM dari agent".

Checkpoint: buka PR percobaan; dalam beberapa menit muncul komentar review dari agent di PR tersebut.

Tambahkan tag mode untuk percakapan lanjutan

Dengan konfigurasi default (tanpa prompt), action masuk tag mode: kamu bisa membalas komentar review dengan @claude perbaiki poin 2 dan agent akan push commit perbaikan ke branch PR β€” persis pola kerja "team" di review loop playbook, tapi terjadi di GitHub, bukan di terminalmu.

Checkpoint: mention @claude di komentar PR menghasilkan balasan atau commit baru di branch itu.

Untuk tool lain polanya sama β€” jalankan CLI non-interaktif di step Actions:

Pakai claude-code-action di atas (jangan install CLI manual di CI β€” action-nya sudah mengurus caching dan output).

Use case 2 β€” Auto-fix test yang gagal (dengan batas)​

Pola: workflow kedua yang hanya jalan kalau workflow test gagal, mencoba memperbaiki, dan push ke branch PR β€” maksimal satu percobaan.

.github/workflows/agent-fix.yml (inti)
on:
workflow_run:
workflows: ["Tests"]
types: [completed]

jobs:
fix:
if: >
github.event.workflow_run.conclusion == 'failure' &&
github.event.workflow_run.event == 'pull_request'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.workflow_run.head_branch }}
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
Test suite gagal di branch ini. Jalankan test, temukan penyebabnya,
dan perbaiki HANYA kode yang menyebabkan kegagalan. Commit dengan
prefix "fix(ci):". Kalau perbaikan butuh mengubah test expectation
atau lebih dari 3 file, JANGAN commit β€” tulis analisis sebagai
komentar PR saja.

Batas "kalau ragu, jangan commit" itu penting: auto-fix yang mengubah test expectation supaya hijau adalah cara tercepat mengirim bug ke production dengan CI yang tersenyum.

Use case 3 β€” Issue-to-PR​

Label issue (mis. agent-ok) sebagai trigger: agent membaca issue, mengerjakan di branch baru, dan membuka draft PR. Gabungkan dengan auto-review di atas dan kamu punya pipeline issue β†’ kode β†’ review yang berjalan tanpa laptop β€” kamu tinggal membaca draft PR dari HP lewat bridge Telegram.

Keamanan secrets & permissions di CI​

:::warning Agent di CI = kode tak terduga berjalan dengan kredensialmu Perlakukan job agent seperti menjalankan kode dari kontributor asing. :::

  1. API key lewat GitHub Secrets, tidak pernah hardcoded β€” dan pakai key terpisah khusus CI supaya mudah dirotasi dan diukur biayanya.
  2. Minimal permissions: per job. Review job cukup contents: read + pull-requests: write. Jangan beri contents: write kecuali job memang harus push.
  3. Waspadai prompt injection dari konten PR/issue. Isi issue dan diff PR adalah input tak tepercaya yang dibaca agent. Jangan jalankan job agent dengan write access pada event pull_request_target dari fork; batasi trigger ke kolaborator (mis. cek github.event.pull_request.author_association).
  4. Branch protection tetap raja. Agent boleh membuka PR dan push ke branch fitur, tapi merge ke main selalu lewat review + CI hijau β€” walaupun reviewer-nya kadang agent lain, keputusan merge tetap milikmu.
  5. Timeout dan concurrency. Set timeout-minutes di tiap job agent dan concurrency per PR supaya dua run agent tidak saling menimpa.

Lanjut ke​