# Kenapa GitHub Actions lambat: henti bina semula setiap job

> GitHub Actions lambat kerana setiap job bermula pada VM kosong dan memuat turun alatnya, memasang semula dependency dan membina semula imej Docker sebelum ujian pertama. Skipbox mengekalkan semuanya pada mesin anda sendiri antara job, pada harga tetap $39 sebulan dengan minit tanpa had: pada 20,000 minit dengan 4 vCPU, itu $183 sebulan lebih murah daripada GitHub.

Kebanyakan masa job GitHub Actions yang lambat berlaku sebelum ujian pertama berjalan. Sediakan Node, muat turun dependency, bina imej Docker: minit yang sama, pada setiap push, sementara seseorang dalam pasukan anda menunggu tanda hijau. Dengan pengebilan ikut minit, anda juga membayar minit itu.

Skipbox ialah runner GitHub Actions yang mengekalkan mesinnya antara job, jadi apa yang dipasang oleh satu job masih ada pada cakera untuk job seterusnya. Tukar satu baris, `runs-on: skipbox`, dan job itu berjalan pada mesin anda sendiri pada harga tetap $39 sebulan dengan minit tanpa had.

- Dependency, lapisan Docker dan alat kekal pada cakera, jadi job melangkau muat turun dan bina semula
- Sekurang-kurangnya 7× ruang cache GitHub, tanpa tamat tempoh 7 hari dan tanpa cache key untuk dilaras
- 20,000 minit sebulan pada 4 vCPU: $222 di GitHub, $39 di Skipbox

**GitHub Actions pada harga tetap, minit tanpa had** Skipbox menjalankan job GitHub Actions anda pada mesin khusus anda sendiri: $39 sebulan, berapa minit pun anda jalankan. Lapisan Docker dan cache dependency kekal antara job, jadi job seterusnya bermula serta-merta.

Runner 4 vCPU, 20,000 minit sebulan: GitHub $222 → Skipbox $39. Anda jimat $183 setiap bulan.

Beralih hanya memerlukan satu baris: `runs-on: skipbox`.

[Mulakan percubaan percuma 7 hari saya](https://app.skipbox.dev/sign-in?ref=g-github-actions-slow-ms)

## Setiap job bermula dari VM kosong

Runner yang dihoskan GitHub ialah mesin maya baharu untuk setiap job. Tiada apa-apa yang dimuat turun atau dibina oleh job terakhir ada padanya, jadi setiap job membina semula keadaan yang sama:

| Step | Runner yang dihoskan GitHub | Skipbox |
|---|---|---|
| Sediakan Node, Python, Java | Memuat turun toolchain | Menemuinya dalam cache alat daripada job terakhir |
| Pasang dependency | Memuat turun dan membuka arkib cache; jika terlepas, muat turun penuh dari registry | Membaca cache pengurus pakej dari cakera |
| Bina imej Docker | Bermula tanpa lapisan dan membina semula setiap step | Menggunakan semula lapisan build terakhir |
| Jalankan ujian | 2 CPU pada `ubuntu-latest` repositori peribadi | 4 vCPU dan ke atas |

Tiga baris pertama tidak menghasilkan apa-apa yang baharu. Ia hanya mengembalikan mesin kepada keadaannya semalam.

Cache GitHub meringankan perkara ini tanpa mengubahnya. Ia memuatkan 10 GB bagi setiap repositori, memadam entri yang tidak dibaca oleh mana-mana job selama 7 hari, dan branch ciri baharu tidak boleh membaca cache branch ciri lain. Malah cache hit pun memuat turun dan membuka arkib pada setiap larian.

## Kos menunggu

Katakan persediaan mengambil 3 minit bagi setiap job dan pasukan anda menjalankan 100 job sehari. Itu 300 minit masa runner sehari yang dihabiskan untuk mengembalikan mesin, dan setiap pull request menunggu bahagiannya. Semakan bermula lebih lewat, merge masuk lebih lewat, dan jurutera beralih kepada kerja lain sementara menunggu.

Dengan pengebilan ikut minit, minit itu ada dalam invois. Runner 4 vCPU, mengikut minit sebulan:

| Minit sebulan (4 vCPU) | GitHub | Skipbox S | Jimat setiap bulan |
|---|---|---|---|
| 10,000 | $102 | $39 | **$63** |
| 20,000 | $222 | $39 | **$183** |
| 30,000 | $342 | $39 | **$303** |

Angka GitHub ialah bil selepas penggunaan yang disertakan dalam GitHub Team. Masukkan minit anda sendiri dalam [kalkulator di laman utama](https://skipbox.dev/?ref=g-github-actions-slow-ms#cost); tanpa perlu log masuk.

Dan bilangan larian hanya meningkat:

- **Ejen pengekodan AI.** Setiap push ejen memulakan CI. Masa menunggu dan bil bertambah mengikut push, bukan bilangan pekerja.
- **Lebih banyak ujian.** Suite E2E atau matrix mengulang persediaan dalam setiap job yang ditambahnya.
- **Bajet.** Hadkan bil dengan bajet GitHub, dan job tidak lagi bermula pada pertengahan bulan, yang menghentikan merge.

## Mempercepatkannya sendiri ialah satu projek

Kekal pada runner yang dihoskan GitHub dan menjadikannya pantas bermakna memikul kerja seperti ini:

- Menetapkan key cache pada hash lockfile dan melaras `restore-keys` sehingga ia hit
- Menambah buildx dan mengeksport cache Docker dengan `cache-to`, dalam 10 GB yang sama
- Memecahkan ujian kepada shard, dengan setiap shard mengulang persediaan dan minit yang dicaj meningkat
- Atau menjalankan self-hosted runner sendiri: penyediaan, kemas kini OS, pembersihan antara job, dan membaikinya apabila ia tergendala

Setiap satu hanya mengelak masalah mesin yang melupakan segalanya. Skipbox mengekalkan mesin itu, jadi semua ini tidak diperlukan.

## Apa yang berubah di Skipbox

**Persediaan kekal pada cakera.** Job anda berjalan pada mesin akaun anda sendiri, dan mesin itu kekal antara job. Imej, lapisan dan cache build Docker; cache pakej untuk npm, pip, Gradle dan lain-lain; alat yang dipasang oleh `setup-node` dan yang seumpamanya. Sekurang-kurangnya 7× ruang cache GitHub, tanpa tamat tempoh selepas 7 hari dan tanpa peraturan branch.

**Mesin lebih besar pada harga tetap.** Pengkompil dan pelari ujian memulakan satu pekerja bagi setiap teras, jadi lebih banyak teras memendekkan step yang terikat pada CPU.

| Pelan | Mesin | Harga |
|---|---|---|
| S | 4 vCPU · 16 GB | $39 sebulan |
| M | 8 vCPU · 16 GB | $79 sebulan |
| L | 16 vCPU · 32 GB | $149 sebulan |

Minit tanpa had pada setiap pelan. Job Skipbox tidak menggunakan minit GitHub, jadi bajet GitHub tidak pernah menghentikannya.

**Tiada mesin untuk dijaga.** Skipbox menyediakan mesin, mengemas kini OS dan alat, membersihkan selepas setiap job, menjalankan semakan kesihatan dan membina semula mesin yang gagal semakan itu.

## Beralih hanya satu baris

```yaml
jobs:
  build:
    runs-on: skipbox # was ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test
```

1. Log masuk ke Skipbox dengan GitHub.
2. Pasang GitHub App Skipbox dan pilih repositori.
3. Tukar `runs-on` dan push.

Apa yang dipasang oleh job pertama ada pada cakera untuk job kedua.

## Keselamatan

- Mesin itu milik akaun anda seorang. Tiada job syarikat lain berjalan padanya.
- Selepas setiap job, bukti kelayakan, proses dan container runner dipadam. Mulai 13 November 2026, checkout anda dan output build-nya (`target/` Cargo) kekal pada mesin anda sendiri untuk job seterusnya; “VM baharu bagi setiap job” memberi setiap job mesin baharu.
- Kod daripada orang tanpa akses tulis (seperti pull request daripada fork) berjalan pada mesin baharu yang dibuang selepas digunakan.

Butirannya ada dalam [cara job diasingkan](https://docs.skipbox.dev/isolation).

## Cuba pada job anda yang paling lambat

Percubaan adalah percuma selama 7 hari atau 3,000 minit job, yang mana dahulu, dan tidak memerlukan kad. Pindahkan job anda yang paling lambat ke `runs-on: skipbox`, jalankannya dua kali berturut-turut, dan letakkan masa setiap step di sebelah masa GitHub.

## Soalan lazim

### Kenapa GitHub Actions sangat lambat?

Setiap job pada runner yang dihoskan GitHub bermula pada VM baharu tanpa apa-apa daripada larian lepas, jadi ia memuat turun alatnya, memasang semula dependency dan membina semula imej Docker sebelum ujian anda bermula. Skipbox menjalankan job anda pada mesin akaun anda sendiri dan mengekalkan keadaan itu pada cakeranya, jadi job seterusnya bermula di tempat job terakhir berhenti.

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

Cache hit masih memuat turun dan membuka arkib pada setiap job, kerana VM itu baharu setiap kali. Dan cache GitHub memuatkan 10 GB bagi setiap repositori, membuang entri yang tidak digunakan selama 7 hari, dan tidak boleh dibaca dari branch bersebelahan. Di Skipbox, cache pakej dan lapisan Docker sudah ada pada cakera mesin, tanpa key untuk diurus.

### Bagaimanakah cara mempercepatkan Docker build dalam GitHub Actions?

Berikan build itu lapisan daripada build terakhir. Pada runner yang dihoskan GitHub, ini bermakna mengeksport cache dengan buildx dan mengimportnya pada setiap larian, dalam had 10 GB yang sama. Di Skipbox, imej dan cache build Docker kekal pada mesin antara job, jadi docker build menggunakan semula lapisan itu dengan sendirinya.

### Perlukah saya menulis semula workflow untuk menggunakan Skipbox?

Tidak. Untuk job Linux, tukar runs-on kepada skipbox. Mesin itu menjalankan Ubuntu 24.04 dengan Docker, Node.js dan Python, dan step serta action anda berjalan seperti biasa.

### Bolehkah saya mencubanya secara percuma pada job saya yang lambat?

Boleh. Percubaan ialah 7 hari atau 3,000 minit job, yang mana dahulu, tanpa kad. Pindahkan job anda yang paling lambat ke runs-on: skipbox, jalankannya dua kali berturut-turut, dan bandingkan masa setiap step dengan GitHub.

Dikemas kini 2026-11-11 · https://skipbox.dev/ms/guides/github-actions-slow