Copilot Fix Failing GitHub Actions: Setup dan Aturan Review

Check merah di pull request pukul 18.40 adalah pajak kecil yang klasik: perbaikannya biasanya lockfile, aturan lint, atau test yang bergeser, tetapi tetap memakan context switch. GitHub kini menaruh tombol tepat di momen itu. Fix with Copilot ada di run yang gagal, dan sejak Juli juga ada di check yang gagal di GitHub Mobile.

Saya belum menjalankan ini di repositori produksi, jadi ini bukan laporan lapangan. Ini pembacaan dekat atas tiga entri changelog GitHub dan empat halaman dokumentasi, dengan setiap klaim ditelusuri ke halaman yang saya buka pada 17 Oktober 2026. Jika sumber diam, misalnya soal biaya, saya katakan begitu, bukan mengisinya. Claude Code punya integrasi Actions sendiri yang dibahas di panduan Claude Code GitHub Actions; tulisan ini hanya tentang Copilot cloud agent.

Apa yang dilakukan tombol ini, dan tiga tanggal perluasannya

Entri pertama bertanggal 18 Mei 2026. Isinya tombol Fix with Copilot di halaman log workflow run. Klik tombol itu meminta Copilot cloud agent memperbaiki job yang gagal: agent menyelidiki di development environment berbasis cloud miliknya, mendorong perbaikan ke branch kamu, dan menandai kamu untuk review. Audiens awalnya Copilot Business dan Copilot Enterprise.

Pada 4 Juni 2026 entri kedua memperluas tombol yang sama ke pelanggan Copilot Pro, Pro+ dan Max. Pada 23 Juli 2026 GitHub Mobile mendapatkannya di check pull request yang gagal, dengan satu perbedaan penting: Copilot membuka pull request baru di atas pull request kamu, bukan mendorong ke dalamnya, lalu menandai kamu untuk review. Entri mobile menyebut iOS dan Android, dan tidak menyebut plan mana yang berhak.

Halaman dokumentasi untuk alur desktop singkat. Syaratnya, workflow run gagal di branch pull request. Langkahnya: buka halaman job dari run yang gagal lalu klik Fix with Copilot, setelah itu Copilot memulai session baru, mencari penyebabnya dan mengirim perbaikan ke branch kamu. Dari empat halaman yang saya baca, tidak ada yang mencantumkan aturan retry atau kuota pemakaian untuk tombol ini.

Apa yang harus diaktifkan admin lebih dulu

Di Business dan Enterprise, tombol ini bukan kamu yang mengaktifkan. Entri Mei menyebut administrator harus menyalakan Copilot cloud agent sebelum kamu bisa mendelegasikan ke sana. Di dokumentasi enterprise, jalurnya AI controls, lalu Agents, lalu Copilot Cloud Agent di bawah Available agents, tempat kamu memilih global policy. Halaman itu menyatakan agent nonaktif secara default.

Cakupannya dua tingkat. Jika memilih Enabled for selected organizations, organisasi dipilih lewat UI, dan memilih berdasarkan custom properties butuh REST API. Secara default agent lalu tersedia di semua repositori organisasi tersebut; owner dapat memblokir repositori tertentu di tingkat organisasi, dan owner serta administrator repositori dapat menonaktifkannya untuk repositori tertentu.

Aturan juga bisa mengunci agent. Halaman about memperingatkan bahwa ruleset atau branch protection rule yang tidak kompatibel dapat memblokir aksesnya, dan administrator dapat memberi Copilot peran bypass actor. Saya akan memutuskan soal bypass itu dengan sengaja, karena itu menentukan apakah agent bisa push sama sekali di branch yang diproteksi. Entri Juni untuk Pro, Pro+ dan Max hanya mencantumkan plan yang memenuhi syarat dan job gagal dengan log; tidak ada langkah admin yang disebut, dan saya tidak menemukannya terdokumentasi untuk plan tersebut.

Apa yang di-push, ke mana, dan apa yang tidak bisa disentuh

Halaman risks adalah pernyataan paling jelas soal jalur tulis. Agent hanya bisa push ke satu branch. Jika dipicu dengan menyebut @copilot di pull request, ia menulis ke branch pull request itu; jika tidak, ia membuat branch copilot baru. Branch protection dan required check tetap berlaku, dan agent tidak bisa menjalankan git push atau perintah git lain secara langsung. Halaman about menambahkan bahwa Copilot bekerja pada satu branch sekali waktu dan membuka satu pull request per task.

Dua batas penting untuk pekerjaan CI. Setiap session punya waktu eksekusi maksimum 59 menit, yang menurut halaman itu tidak bisa diperpanjang atau di-bypass, jadi kegagalan yang butuh satu jam integration test untuk direproduksi di luar jangkauan tombol ini. Dan hanya repositori yang di-host di GitHub yang didukung. Tabel berikut menaruh tiga cara mendapat bantuan atas run yang gagal berdampingan, hanya dengan apa yang dinyatakan sumber.

Explain error adalah saudaranya yang lebih rendah risiko. Ia hanya membuka jendela chat tempat Copilot memberi instruksi untuk menyelesaikan masalah, jadi tidak ada yang di-push. Saya akan memakainya lebih dulu setiap kali belum tahu apakah kegagalannya di kode atau di infrastruktur.

Beri agent environment yang sama dengan CI kamu

Agent berjalan di environment-nya sendiri, dan perbaikan yang tidak bisa dites hanyalah tebakan. Dokumentasi customisasi menjelaskan file workflow di .github/workflows/copilot-setup-steps.yml. File itu baru terpicu setelah ada di default branch, dan harus berisi satu job bernama copilot-setup-steps, kalau tidak Copilot tidak akan memakainya. Hanya key ini di job itu yang dipakai: steps, permissions, runs-on, services, snapshot dan timeout-minutes.

Tiga perilaku dari halaman yang sama patut diketahui. timeout-minutes maksimum 59. fetch-depth yang kamu set di actions/checkout ditimpa agar agent bisa me-rollback commit. Dan jika satu setup step keluar dengan kode non-zero, step sisanya dilewati dan Copilot mulai dengan kondisi environment yang tercapai, jadi npm ci yang gagal tidak menghentikan session, melainkan diam-diam memberi agent tanpa dependency. Contoh berikut hanya memakai key yang dipakai; perintah install-nya milik saya, untuk project Node.

# .github/workflows/copilot-setup-steps.yml
# Must be on the default branch, and the job MUST be named copilot-setup-steps.
# Only steps, permissions, runs-on, services, snapshot and timeout-minutes
# are honoured; anything else in the job is ignored.
name: "Copilot Setup Steps"

on:
  workflow_dispatch:          # run it by hand once to prove the steps pass
  pull_request:
    paths: [".github/workflows/copilot-setup-steps.yml"]

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest    # Ubuntu x64 or Windows 64-bit only
    timeout-minutes: 30       # 59 is the documented ceiling
    permissions:
      contents: read          # needed because the steps clone the repository
    steps:
      - uses: actions/checkout@v4   # fetch-depth is overridden by Copilot anyway
      - uses: actions/setup-node@v4
        with:
          node-version-file: ".nvmrc"
          cache: npm
      # A non-zero exit here skips the remaining steps and the session STILL
      # starts, just without dependencies. Keep this step fatal in CI terms
      # by running the same command your real workflow runs.
      - run: npm ci

Halaman yang sama menyebut agent hanya mendukung runner Ubuntu x64 Linux dan Windows 64-bit, dan self-hosted runner butuh integrated firewall Copilot dinonaktifkan karena tidak kompatibel. Jika job yang gagal berjalan di macOS, agent tidak bisa mereproduksinya.

Celah approval: push-nya tidak menjalankan check kamu

Ini bagian yang akan saya jelaskan ke seluruh tim. Dokumentasi Copilot menyatakan secara default workflow GitHub Actions tidak berjalan otomatis ketika Copilot mendorong perubahan ke pull request; kamu mungkin perlu mengklik Approve and run workflows di merge box. Halaman risks membingkainya sebagai mitigasi: workflow tidak berjalan sampai kode di-review dan user dengan akses write mengklik tombol itu, dengan opsi mengizinkan run otomatis.

Akibatnya jebakan bagi siapa pun yang membaca status sekilas. Setelah agent push, pull request masih bisa menampilkan check merah lama atau tidak ada check baru sama sekali, tergantung pengaturan branch protection kamu. Perbaikannya belum diverifikasi CI kamu. Perintah berikut menanyakan hal yang penting: apakah ada run di commit yang di-push agent, dan apa kesimpulannya.

PR=123

# The commit the agent pushed (the PR head), and the branch it lives on.
HEAD_SHA=$(gh pr view "$PR" --json headRefOid --jq .headRefOid)
BRANCH=$(gh pr view "$PR" --json headRefName --jq .headRefName)

# Wrong: trust the rollup on the PR page. It may describe an older commit,
# or nothing, if workflows are still waiting for "Approve and run workflows".
gh pr checks "$PR"

# Right: ask whether any run exists for exactly this commit, and what it said.
gh run list --branch "$BRANCH" --limit 10 \
  --json databaseId,event,headSha,status,conclusion \
  --jq ".[] | select(.headSha == \"$HEAD_SHA\")"
# Empty output means CI has not verified the agent's fix yet.

Aturan review agar perbaikannya jujur

Kontrol review GitHub ada di pihak kamu di sini, dan spesifik. Manusia harus me-review dan me-merge pull request yang dibuka agent; agent tidak bisa menandainya siap, menyetujuinya, atau me-merge-nya. User yang meminta Copilot membuat pull request tidak bisa menyetujuinya. Jika pull request tidak dikaitkan ke seseorang dan repositori mensyaratkan minimal satu approval, dibutuhkan satu approval tambahan. Approval tambahan itu aktif secara default di ruleset, tempat admin bisa mematikannya, dan selalu berlaku pada branch protection rule.

Tabel memetakan tiap kontrol dari halaman risks ke kegagalan yang ditanganinya. File CODEOWNERS sesudahnya adalah tambahan saya, bukan yang diresepkan sumber: ia memastikan file yang bisa dilemahkan agent demi centang hijau selalu butuh manusia bernama.

# .github/CODEOWNERS
# The files an agent could weaken to turn a red check green always need a
# named human, whoever (or whatever) opened the pull request.
/.github/workflows/   @acme/platform-team
/.github/CODEOWNERS   @acme/platform-team
/tests/               @acme/qa-owners
/eslint.config.mjs    @acme/platform-team
/package-lock.json    @acme/platform-team

Baris terakhir adalah alasan saya membaca halaman risks dengan teliti. Agent membaca log job yang gagal, dan log menggemakan apa pun yang dicetak test dan tool kamu. Halaman itu mendokumentasikan penyaringan hidden character di issue dan komentar, tetapi saya tidak menemukan pernyataan soal isi log, jadi saya memperlakukan log sebagai input tak tepercaya dan menjaga scope token agent tetap kecil.

Di mana ini salah: hijau karena dilemahkan

Cara termurah mengubah check merah jadi hijau adalah mengubah check-nya. Test di-skip, aturan lint dilonggarkan, timeout dinaikkan, kondisi workflow dilonggarkan. Sumber tidak melaporkan agent melakukan ini; mereka menyebut output bisa salah atau tidak aman, log tidak menggantikan review dan testing kamu sendiri, dan output harus di-review dan dites sebelum dipakai di produksi. Saya membacanya sebagai dorongan untuk mencari tepat bentuk perubahan ini.

Maka saya me-review diff agent dengan urutan tetap: pertama apa pun di direktori workflow dan direktori test, lalu file dependency, baru perubahan source yang seharusnya menjadi perbaikannya. Perbaikan yang sebagian besar ada di dua kelompok pertama adalah perubahan atas definisi sukses, dan layak ditanya kenapa kodenya sendiri tidak perlu berubah.

# Review order for an agent fix. Read the "definition of success" first.
BASE=origin/main

# 1. Did it touch the checks themselves? Any hit needs a written reason.
git diff --stat $BASE...HEAD -- .github/ tests/ '*.test.*' '*.spec.*'

# 2. Did it quietly skip or loosen something?
git diff $BASE...HEAD | grep -nE '^\+.*(\.skip|xit\(|xdescribe|eslint-disable|continue-on-error|timeout-minutes)'

# 3. Dependencies, then finally the source change that was meant to be the fix.
git diff --stat $BASE...HEAD -- package.json package-lock.json
git diff $BASE...HEAD -- src/

Batas lainnya bersifat struktural. Kegagalan karena secret kedaluwarsa, layanan pihak ketiga yang flaky, atau runner outage bukan masalah kode, dan session agent yang menghabiskan 59 menit untuk itu menghasilkan patch meyakinkan untuk penyebab yang salah. Baca sendiri step pertama yang gagal sebelum menekan tombol, dan tekan untuk kegagalan yang memang soal kode.

Yang dilakukan pada hari Senin

Lima langkah berurutan, masing-masing cukup kecil untuk selesai dalam satu sore.

1. Tanyakan ke admin enterprise atau organisasi apakah Copilot cloud agent sudah aktif, dan di repositori mana. Di Business dan Enterprise ia nonaktif secara default.
2. Tambahkan copilot-setup-steps.yml ke default branch dengan toolchain dan langkah install yang sama dengan CI kamu, lalu jalankan sekali secara manual untuk memastikan berhasil.
3. Putuskan soal ruleset: apakah Copilot mendapat peran bypass actor, dan apakah aturan approval tambahan dibiarkan aktif untuk pull request buatan agent.
4. Tambahkan entri CODEOWNERS untuk direktori workflow dan test agar file yang bisa dilemahkan agent selalu butuh reviewer bernama.
5. Tulis urutan review dari bagian sebelumnya ke template pull request, dan jadikan persetujuan workflow run langkah eksplisit setelah membaca diff.

Setelah perbaikan agent pertama, periksa apakah ada run di head commit-nya, dan catat biayanya. Halaman yang saya baca menjelaskan pemakaian hanya lewat tautan ke halaman billing, jadi saya tidak bisa memberi tahu berapa biaya satu session; lihat billing dan usage kamu sendiri sebelum memperluas rollout.

Fix with Copilot adalah delegasi yang bagus untuk kegagalan yang jelas soal kode, dan buruk untuk kegagalan soal dunia di sekitarnya. Aturan yang saya bawa: agent boleh mengusulkan perbaikan, tetapi CI kamu harus memverifikasinya, dan manusia harus membaca apa yang berubah di check itu sendiri sebelum apa pun di-merge.