Skipbox

Kenapa GitHub Actions lambat? Hentikan setup ulang di tiap job

Sebagian besar waktu job GitHub Actions yang lambat habis sebelum test pertama berjalan. Siapkan Node, unduh dependensi, build image Docker: menit yang sama, di setiap push, sementara seseorang di tim Anda menunggu centang hijau. Dengan penagihan per menit, menit-menit itu juga Anda bayar.

Skipbox adalah runner GitHub Actions yang menyimpan mesinnya di antara job, jadi apa yang dipasang satu job masih ada di disk untuk job berikutnya. Ubah satu baris, runs-on: skipbox, dan job berjalan di mesin milik Anda dengan harga tetap $39 per bulan dan menit tanpa batas.

Setiap job dimulai dari VM kosong

Runner yang dihosting GitHub adalah mesin virtual baru untuk setiap job. Tidak ada yang diunduh atau di-build job sebelumnya di sana, jadi setiap job membangun ulang keadaan yang sama:

Tiga baris pertama tidak menghasilkan apa pun yang baru. Semuanya mengembalikan mesin ke keadaan kemarin.

Cache GitHub meringankan hal ini tanpa mengubahnya. Cache itu menampung 10 GB per repositori, menghapus entri yang tidak dibaca job mana pun selama 7 hari, dan feature branch baru tidak bisa membaca cache feature branch lain. Bahkan saat hit, arsip tetap diunduh dan diekstrak di setiap run.

Harga dari menunggu

Misalkan setup memakan 3 menit dari setiap job dan tim Anda menjalankan 100 job sehari. Itu 300 menit waktu runner per hari yang dipakai untuk mengembalikan mesin ke keadaan semula, dan setiap pull request menunggu bagiannya. Review dimulai lebih lambat, merge masuk lebih lambat, dan engineer beralih ke pekerjaan lain sambil menunggu.

Dengan penagihan per menit, menit-menit itu muncul di invoice. Runner 4 vCPU, menurut menit per bulan:

Angka GitHub adalah tagihan setelah dikurangi kuota bawaan GitHub Team. Masukkan menit Anda sendiri di kalkulator di beranda; tidak perlu masuk.

Dan jumlah run hanya bertambah:

  • AI coding agent. Setiap push dari agent memulai CI. Waktu tunggu dan tagihan naik mengikuti jumlah push, bukan jumlah orang.
  • Test bertambah. Suite E2E atau matrix mengulang setup di setiap job yang ditambahkannya.
  • Anggaran. Batasi tagihan dengan anggaran GitHub, dan job berhenti dimulai di tengah bulan, yang menghentikan merge.

Mempercepatnya sendiri adalah proyek tersendiri

Bertahan di runner yang dihosting GitHub dan membuatnya cepat berarti mengambil pekerjaan seperti ini:

  • Membuat cache key dari hash lockfile dan menyetel restore-keys sampai cache-nya hit
  • Menambahkan buildx dan mengekspor cache Docker dengan cache-to, tetap dalam batas 10 GB yang sama
  • Membagi test ke beberapa shard, padahal setiap shard mengulang setup dan menit yang ditagih bertambah
  • Atau menjalankan self-hosted runner sendiri: menyiapkan mesin, memperbarui OS, membersihkan sisa di antara job, dan memperbaikinya saat mati

Semuanya mengakali mesin yang melupakan segalanya. Skipbox mempertahankan mesinnya, jadi semua itu tidak diperlukan.

Yang berubah di Skipbox

Hasil setup tetap ada di disk. Job Anda berjalan di mesin milik akun Anda, dan mesin itu tetap ada di antara job. Image, layer, dan build cache Docker; cache paket untuk npm, pip, Gradle, dan lainnya; tool yang dipasang setup-node dan sejenisnya. Ruang cache minimal 7× GitHub, tanpa kedaluwarsa setelah 7 hari dan tanpa aturan branch.

Mesin lebih besar dengan harga tetap. Compiler dan test runner memulai satu worker per core, jadi core yang lebih banyak mempersingkat step yang bergantung pada CPU.

Menitnya tanpa batas di setiap paket. Job Skipbox tidak memakai menit GitHub, jadi anggaran GitHub tidak pernah menghentikannya.

Tanpa mesin yang perlu dijaga. Skipbox menyiapkan mesin, memperbarui OS dan tool, membersihkan sisa setiap job, menjalankan health check, dan membangun ulang mesin yang gagal.

Pindah cukup satu baris

jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
  1. Masuk ke Skipbox dengan GitHub.
  2. Instal aplikasi GitHub Skipbox dan pilih repositorinya.
  3. Ubah runs-on, lalu push.

Apa yang dipasang job pertama sudah ada di disk untuk job kedua.

Keamanan

  • Mesinnya hanya milik akun Anda. Tidak ada job perusahaan lain yang berjalan di sana.
  • Setelah setiap job, kredensial runner, proses, dan container dihapus. Mulai 13 November 2026, checkout Anda dan output build-nya (target/ milik Cargo) tetap ada di mesin milik Anda untuk job berikutnya; Bersih setiap job memberi setiap job mesin baru.
  • Kode dari orang tanpa akses tulis (misalnya pull request dari fork) berjalan di mesin baru sekali pakai.

Detailnya ada di cara job diisolasi.

Coba di job Anda yang paling lambat

Uji cobanya gratis selama 7 hari atau 3.000 menit job, mana yang lebih dulu tercapai, dan tanpa kartu. Pindahkan job Anda yang paling lambat ke runs-on: skipbox, jalankan dua kali berturut-turut, lalu bandingkan waktu setiap step dengan di GitHub.

FAQ

Kenapa GitHub Actions lambat sekali?

Setiap job di runner yang dihosting GitHub dimulai di VM baru tanpa sisa apa pun dari run sebelumnya, jadi job itu mengunduh tool, memasang ulang dependensi, dan membangun ulang image Docker sebelum test Anda dimulai. Skipbox menjalankan job Anda di mesin milik akun Anda dan menyimpan semua itu di disknya, jadi job berikutnya mulai dari titik job sebelumnya berhenti.

Saya sudah menambahkan actions/cache. Kenapa workflow saya masih lambat?

Cache hit pun tetap mengunduh dan mengekstrak arsip di setiap job, karena VM-nya selalu baru. Selain itu, cache GitHub menampung 10 GB per repositori, menghapus entri yang tidak dipakai selama 7 hari, dan tidak bisa dibaca dari branch sejajar. Di Skipbox, cache paket dan layer Docker sudah ada di disk mesin, tanpa key yang perlu diurus.

Bagaimana cara mempercepat build Docker di GitHub Actions?

Beri build itu layer dari build sebelumnya. Di runner yang dihosting GitHub, itu berarti mengekspor cache dengan buildx dan mengimpornya di setiap run, tetap dalam batas 10 GB yang sama. Di Skipbox, image dan build cache Docker tetap ada di mesin di antara job, jadi docker build memakai ulang layer-nya dengan sendirinya.

Apakah saya harus menulis ulang workflow untuk memakai Skipbox?

Tidak. Untuk job Linux, ubah runs-on menjadi skipbox. Mesinnya menjalankan Ubuntu 24.04 dengan Docker, Node.js, dan Python, dan step serta action Anda berjalan seperti apa adanya.

Bisakah saya mencobanya gratis di job saya yang lambat?

Bisa. Uji cobanya 7 hari atau 3.000 menit job, mana yang lebih dulu tercapai, tanpa kartu. Pindahkan job Anda yang paling lambat ke runs-on: skipbox, jalankan dua kali berturut-turut, lalu bandingkan waktu setiap step dengan di GitHub.

Diperbarui 11 November 2026

CI/CD lebih cepat dengan cache yang selalu hangat

Runner hangat Anda dengan harga tetap

1/12 biaya GitHub saat dipakai penuh. Harga tetap, jadi bisa jalan seharian. Ruang cache 7× GitHub.

  • Tanpa kartu
  • Masuk dengan GitHub
  • Batalkan kapan saja