Jawaban singkat: Untuk memperbaiki CI yang gagal menggunakan AI agent, kirim event kegagalan CI ke webhook, biarkan coding agent memeriksa apakah kegagalan tersebut dapat ditanganinya, mereproduksinya secara lokal di worktree yang bersih, lalu mengirimkan (push) perbaikan ke branch sebagai draft pull request. Pengembang manusia kemudian meninjau dan menggabungkannya (merge). Jika tidak dapat direproduksi secara lokal, jangan lakukan push.
Build yang memerah (gagal) pada jam 4 sore memakan biaya lebih besar daripada proses perbaikannya itu sendiri. Seseorang harus menghentikan pekerjaannya, membuka log, menggulir melewati 900 baris output setup, dan menemukan kesalahan lint atau snapshot yang usang. Perbaikannya hanya butuh dua menit, tetapi context switch-nya menyita waktu dua puluh menit.
Celah inilah tempat coding agent membuktikan manfaatnya. Anda mungkin sudah menggunakan Claude Code, Codex, atau agent lain di perangkat kerja Anda. Bagian yang hilang hanyalah penghubungnya: mekanisme yang mendeteksi kegagalan, meneruskannya ke agent beserta konteks yang tepat, dan mencegah agent melakukan push hasil tebakan ke repositori Anda. Panduan ini membangun alur penghubung tersebut menggunakan GitHub Actions dan Automations dari Sharkly, dan pola yang sama dapat diterapkan pada sistem CI mana pun yang mampu mengirimkan HTTP request.
Apa saja yang dapat (dan tidak dapat) diperbaiki dengan baik oleh AI agent di CI
Agent bekerja paling optimal untuk menangani kegagalan yang dapat direproduksi di laptop dan memiliki perbaikan kecil yang mudah diverifikasi. Sebaliknya, agent paling tidak cocok untuk menangani masalah pada infrastruktur, kredensial, atau layanan pihak ketiga. Pilah terlebih dahulu sebelum Anda melakukan otomatisasi:
| Jenis kegagalan | Kesesuaian agent | Alasan |
|---|---|---|
| Kesalahan lint dan pemformatan | Sangat Cocok | Bersifat deterministik; linter dapat memverifikasi perbaikannya secara langsung |
| Kesalahan tipe data (type errors) | Sangat Cocok | Kompiler memverifikasi perbaikannya secara langsung |
| Snapshot rusak setelah perubahan UI yang disengaja | Baik | Mudah direproduksi, tetapi pengembang manusia perlu memastikan bahwa perubahan tersebut memang disengaja |
| Pengujian tidak konsisten (flaky test) | Bervariasi | Reproduksi membutuhkan eksekusi berulang kali; perbaikannya sering kali merupakan race condition yang nyata |
| Unit test gagal setelah perubahan logika | Bervariasi | Bisa jadi unit test-nya yang benar dan kodenya yang salah |
| Disk runner penuh, batas waktu jaringan habis (timeout) | Buruk | Tidak ada yang perlu diperbaiki di repositori |
| Secret hilang atau kedaluwarsa, izin akses bermasalah | Jangan Pernah | Agent tidak boleh menyentuh kredensial sama sekali |
Aturan utama yang dapat disimpulkan dari tabel ini: agent hanya boleh mengirimkan perbaikan setelah memastikannya sendiri berubah dari merah (gagal) menjadi hijau (berhasil) di Computer miliknya. Sebuah esai perancangan yang diunggah oleh tim DeepSeek Harness di X menyebut pola ini sebagai “silently reproduce and fix”: sebuah trigger memantau event, secara default tetap diam, dan hanya memunculkan perbaikan sederhana yang sudah terkonfirmasi. Esai tersebut memang menjelaskan desain purwarupa, bukan produk yang sudah dirilis, tetapi prinsipnya tetap relevan untuk konfigurasi apa pun yang Anda bangun sendiri.
Cara kerja alur perbaikan CI
Alur ini terdiri dari lima bagian: event kegagalan, webhook bertanda tangan, filter ringan, reproduksi terisolasi, dan gerbang peninjauan manusia.
- CI Anda menyelesaikan proses eksekusi dengan status gagal.
- Workflow sederhana mengirimkan body JSON yang telah ditandatangani ke URL webhook.
- Agent membaca body tersebut dan mengabaikan apa pun yang berada di luar cakupan, seperti repositori yang salah atau kegagalan pada branch rilis.
- Agent membuat task, melakukan checkout worktree baru yang bersih, mereproduksi kegagalan tersebut, lalu memperbaikinya.
- Agent melakukan push ke branch dan membuka draft pull request. Pengembang manusia kemudian memutuskan untuk menggabungkan (merge) atau menutupnya.
Langkah 3 dan 4 berjalan sebagai Sharkly Automation. Automation adalah rangkaian instruksi tersimpan beserta Agent atau Crew yang menjalankannya, yang diinisiasi oleh trigger: jadwal berkala, perubahan status task, frasa komentar, atau webhook.
Langkah 1: Kirim kegagalan CI ke webhook
GitHub Actions memiliki event workflow_run yang terpicu saat workflow lain selesai berjalan. Event ini aktif di setiap hasil eksekusi (conclusion), sehingga Anda perlu memfilternya ke failure menggunakan job condition. Satu hal penting dari dokumentasi GitHub: file workflow harus berada di branch default, jika tidak, workflow ini tidak akan pernah terpicu.
Workflow ini memantau workflow bernama CI, menyusun body JSON sederhana, menandatanganinya, dan mengirimkannya:
name: Report CI failure
on:
workflow_run:
workflows: [CI]
types: [completed]
jobs:
notify:
if: ${{ github.event.workflow_run.conclusion == 'failure' }}
runs-on: ubuntu-latest
steps:
- name: Send signed webhook
env:
WEBHOOK_URL: ${{ secrets.SHARKLY_WEBHOOK_URL }}
SIGNING_SECRET: ${{ secrets.SHARKLY_SIGNING_SECRET }}
REPO: ${{ github.repository }}
RUN_ID: ${{ github.event.workflow_run.id }}
RUN_URL: ${{ github.event.workflow_run.html_url }}
BRANCH: ${{ github.event.workflow_run.head_branch }}
SHA: ${{ github.event.workflow_run.head_sha }}
run: |
BODY=$(jq -nc --arg repo "$REPO" --arg run_id "$RUN_ID" \
--arg url "$RUN_URL" --arg branch "$BRANCH" --arg sha "$SHA" \
'{event:"ci_failure",repo:$repo,run_id:$run_id,run_url:$url,branch:$branch,sha:$sha}')
TS=$(date +%s)
SIG=$(printf '%s\n%s' "$TS" "$BODY" \
| openssl dgst -sha256 -hmac "$SIGNING_SECRET" -binary | base64)
curl -fsS -X POST "$WEBHOOK_URL" \
-H "Content-Type: application/json" \
-H "X-Webhook-Timestamp: $TS" \
-H "X-Webhook-Signature: v1=$SIG" \
--data-raw "$BODY"
Nama branch berasal dari kontributor, sehingga workflow meneruskannya melalui env dan jq alih-alih menempelkannya langsung ke skrip shell. Simpan kedua nilai tersebut sebagai encrypted repository secrets, dan jangan pernah menuliskannya langsung di dalam file.
Langkah 2: Buat Automation beserta webhook trigger-nya
Di Space Anda, buat sebuah Automation, tetapkan ke Agent yang bertugas melakukan perbaikan, dan tambahkan trigger Webhook. Sharkly hanya menampilkan URL lengkap satu kali saat Anda membuat atau memperbarui (regenerate) trigger, jadi langsung salin URL tersebut ke secret GitHub Anda.
Aktifkan signing secret. Tanpa secret ini, URL akan berfungsi sebagai bearer secret: siapa pun yang memilikinya dapat memicu eksekusi. Jika diaktifkan, sesuai dokumentasi Automations, setiap request wajib menyertakan header X-Webhook-Signature bernilai v1= ditambah Base64 HMAC-SHA256 dari timestamp, baris baru (newline), dan raw body, yang di-hash menggunakan secret whsec_. Sharkly akan menolak timestamp yang berselisih lebih dari 300 detik dan hanya menerima tanda tangan tertentu satu kali dalam kurun waktu 10 menit, sehingga request yang disadap tidak dapat dikirim ulang (replay attack).
Trigger harus diaktifkan dan status Automation harus Active sebelum request yang valid dapat memulai eksekusi. Lakukan pengujian dengan tombol Run now terlebih dahulu.
Langkah 3: Tulis instruksi dengan prinsip filter terlebih dahulu, perbaiki kemudian
Eksekusi Automation yang dipicu oleh webhook tidak otomatis membuat task tersendiri. Karena proses eksekusi tidak memiliki task tertaut, instruksi Anda harus membuat task baru; hal ini memberikan rekam jejak untuk setiap kegagalan, wadah diskusi untuk pertanyaan, serta status yang dapat dipantau oleh tim Anda. Tempatkan pemeriksaan cepat dan ringan di urutan teratas agar sebagian besar event selesai dalam hitungan detik:
You receive a CI failure webhook. The trigger payload is JSON with
event, repo, run_id, run_url, branch, sha.
1. Stop with no output unless event == "ci_failure" and repo is
acme/web. Stop if branch starts with "release/".
2. Search open tasks for run_id. If one exists, stop.
3. File a task titled "CI fix: <repo> run <run_id>" with run_url in
the body. Do all further work under that task.
4. Read the failed steps: gh run view <run_id> --log-failed
5. If the cause is a secret, permission, runner, or network problem,
comment the diagnosis on the task and stop. Change nothing.
6. Check out sha in a fresh worktree. Run the failing command and
confirm it fails the same way. If it does not reproduce, comment
what you tried and stop. Never push an unreproduced fix.
7. Make the smallest change that fixes it. Do not edit CI config,
lockfiles, or tests you were not asked to fix. Rerun the command
and the nearest test suite.
8. Push to branch ci-fix/<TASK-ID> and open a draft PR with
gh pr create --draft, task ID in the title. Comment the PR link
on the task and hand it to a human for review.
Ada dua detail penting di sini. Saat ini, trigger status dan komentar cocok di seluruh tingkat organisasi, itulah sebabnya dokumentasi menyarankan untuk memvalidasi input di dalam instruksi; webhook memang dibatasi pada URL-nya, tetapi langkah 1 tetap berfungsi sebagai pengaman jika ada request yang salah rute. Selain itu, ID task pada nama branch memiliki fungsi penting: saat integrasi GitHub terhubung, adanya ID task pada nama branch, judul PR, atau isi PR akan langsung menautkan pull request kembali ke task terkait.
Langkah 4: Jalankan di Computer dalam worktree terisolasi
Computer adalah host terhubung tempat Agent Anda berjalan, lengkap dengan Runtime, file, dan kredensial Git miliknya sendiri. Atur repositori Agent ke mode Temporary agar setiap proses eksekusi mendapatkan direktori task tersendiri dan worktree terpisah. Dengan begitu, dua kegagalan yang terjadi hanya berselang satu menit tidak akan menimpa file satu sama lain. Untuk penjelasan teknis lebih lanjut, silakan baca parallel agents in isolated worktrees dan referensi git worktree.
Akses Git berasal dari Computer, bukan dari GitHub App. Integrasi hanya bertugas menautkan pull request dan menyinkronkan issue; proses cloning dan pushing tetap menggunakan SSH key, token HTTPS, atau login gh pada host tersebut. Berikan hak akses push pada kredensial tersebut hanya untuk branch, dan lindungi branch default Anda agar proses merge selalu mewajibkan review.
Biaya dan batas pengaman (guardrails)
Biaya setiap eksekusi ditagihkan ke paket Runtime masing-masing. Sharkly tidak menjual token, sehingga biaya eksekusi perbaikan CI sama persis dengan biaya sesi Claude Code atau Codex berdurasi serupa yang Anda gunakan saat ini. Filter jalur cepat (fast-path) pada langkah 1 merupakan pengendali biaya utama Anda: event yang langsung berhenti di langkah 1 hanya menghabiskan beberapa ratus token, bukan biaya penuh untuk reproduksi masalah.
Konkurensi adalah mekanisme kendali kedua. Setiap Computer memiliki batas concurrent-task, dan proses yang berjalan di direktori temporer secara default menggunakan separuh dari batas tersebut. Saat kapasitas penuh, proses tambahan akan masuk antrean alih-alih membebani satu laptop secara bersamaan. Pagi hari yang buruk dengan 30 build merah pun akan menjadi antrean rapi, bukan insiden crash.
Sisanya adalah aturan yang cukup Anda tentukan sekali:
- Hanya buat draft PR. Agent tidak boleh melakukan merge sendiri. Lihat panduan human-in-the-loop coding agents untuk menentukan di mana review gate seharusnya ditempatkan.
- Satu kali percobaan per eksekusi. Jika perbaikan pertama gagal saat pengujian ulang, agent akan meninggalkan komentar dan berhenti.
- Daftar larangan (deny list): konfigurasi CI, secret, lockfile, dan migrasi.
- Jeda Automation dari halamannya saat Anda mengubah instruksi, lalu aktifkan kembali setelah mengujinya dengan Run now.
Lakukan verifikasi sebelum memercayainya sepenuhnya. Pola plan, observe, verify loop sangat berlaku di sini: pelajari riwayat eksekusi selama seminggu sebelum Anda memperluas daftar repositori yang didukung.
Alternatif
Anda dapat membuat task untuk setiap kegagalan alih-alih menggunakan webhook Automation. Arahkan workflow ke skrip yang memanggil sharkly task create, lalu biarkan Agent yang ditugaskan menanganinya. Pendekatan ini akan menghasilkan task untuk setiap build yang merah—termasuk yang sebenarnya harus diabaikan oleh agent—sehingga lebih cocok untuk repositori bervolume rendah. Tim yang sudah mengelola issue melalui GitHub juga dapat memulai dengan menugaskan GitHub issue ke AI agent.
Mulai dari satu repositori
Pilihlah repositori yang paling sering mengalami kegagalan lint dan type error, pasang alur workflow di atas, lalu jalankan Automation secara manual sebanyak tiga kali sebelum membiarkan webhook bekerja otomatis. Jika Anda sudah siap beralih ke skala yang lebih besar dari satu agent, panduan cara menjalankan 10 AI coding agent sekaligus akan memandu langkah selanjutnya. Sharkly dapat digunakan secara gratis untuk memulai: hubungkan Computer dan biarkan agent yang sudah Anda miliki menangani build merah berikutnya.
FAQ
Bisakah AI agent memperbaiki build CI yang gagal secara mandiri?
Agent dapat memperbaiki kesalahan lint, tipe data, dan snapshot yang berhasil direproduksinya secara lokal. Namun, agent tidak boleh melakukan merge secara otomatis. Tetap batasi output-nya sebagai draft PR dan biarkan pengembang manusia yang menyetujuinya.
Bagaimana cara memicu AI agent saat GitHub Actions gagal?
Tambahkan workflow pada event workflow_run dengan types: [completed] dan kondisi job pada conclusion == 'failure'. Job tersebut akan mengirimkan request bertanda tangan ke URL webhook milik agent.
Apa yang mencegah agent melakukan push terhadap perbaikan yang salah?
Aturan reproduksi lokal. Agent harus melihat sendiri kegagalan tersebut di lingkungan lokal, menerapkan perubahan, dan memastikan perintah yang sama berhasil dieksekusi. Jika kegagalan tidak dapat direproduksi, agent hanya akan meninggalkan komentar di task tanpa melakukan push.
Apakah integrasi GitHub di Sharkly otomatis membuka pull request?
Tidak. Integrasi tersebut hanya menautkan pull request ke task dan menyinkronkan issue. Agent yang akan membuka PR menggunakan kredensial Git dan gh yang ada di Computer-nya.
Bagaimana dengan flaky test (pengujian yang tidak konsisten)?
Instruksikan agent untuk menjalankan ulang pengujian yang gagal beberapa kali sebelum mengambil keputusan. Jika tes tersebut lolos di beberapa percobaan dan gagal di percobaan lain, agent harus melaporkan masalah inkonsistensi (flake) tersebut pada task, alih-alih membuat perbaikan sembarangan di sekitarnya.
Berapa biaya eksekusi perbaikan CI?
Hanya sebesar token yang digunakan oleh Runtime Anda selama sesi tersebut. Biaya eksekusi Sharkly ditagihkan langsung ke paket Claude Code, Codex, atau API yang Anda gunakan.
