De ce e lent GitHub Actions: nu mai reface totul la fiecare job

Cea mai mare parte dintr-un job GitHub Actions lent se petrece înainte să ruleze primul test. Setezi Node, descarci dependențele, construiești imaginea Docker: aceleași minute, la fiecare push, în timp ce cineva din echipă așteaptă o bifă verde. La facturarea la minut plătești și pentru minutele acestea.

Skipbox este un runner GitHub Actions care își păstrează mașina între joburi, așa că ce a instalat un job e încă pe disc pentru următorul. Schimbi o singură linie, runs-on: skipbox, iar jobul rulează pe mașina ta la un preț fix de $39 pe lună, cu minute nelimitate.

Fiecare job pornește de pe un VM gol

Un runner găzduit de GitHub este o mașină virtuală nouă pentru fiecare job. Pe ea nu e nimic din ce a descărcat sau a construit jobul anterior, așa că fiecare job reface aceeași stare:

Primele trei rânduri nu produc nimic nou. Doar aduc mașina înapoi unde era ieri.

Cache-ul GitHub atenuează asta fără să o schimbe. Are 10 GB per repository, șterge intrările pe care niciun job nu le-a citit de 7 zile, iar o ramură nouă de feature nu poate citi cache-ul altei ramuri de feature. Chiar și la un cache hit, fiecare rulare descarcă și dezarhivează o arhivă.

Cât te costă așteptarea

Să zicem că setup-ul ia 3 minute din fiecare job, iar echipa ta rulează 100 de joburi pe zi. Asta înseamnă 300 de minute pe zi de timp de runner folosite ca să aduci mașina înapoi, iar fiecare pull request își așteaptă partea. Review-urile încep mai târziu, merge-urile ajung mai târziu, iar inginerii trec la altceva cât așteaptă.

La facturarea la minut, minutele acestea apar pe factură. Un runner de 4 vCPU, după minutele lunare:

Cifrele GitHub sunt factura după utilizarea inclusă în GitHub Team. Introdu propriile minute în calculatorul de pe pagina principală; nu cere conectare.

Iar numărul de rulări doar crește:

• Agenții AI de programare. Fiecare push al unui agent pornește CI-ul. Așteptarea și factura cresc odată cu push-urile, nu cu numărul de oameni.
• Mai multe teste. O suită E2E sau o matrice repetă setup-ul în fiecare job pe care îl adaugă.
• Bugete. Plafonezi factura cu un buget GitHub, iar joburile nu mai pornesc la mijlocul lunii, ceea ce oprește merge-urile.

Să îl accelerezi singur e un proiect întreg

Dacă rămâi pe runnerele găzduite de GitHub și vrei să le faci rapide, îți iei pe cap muncă de felul acesta:

• Chei de cache după hash-ul lockfile-urilor și reglarea restore-keys până nimeresc
• Adăugarea buildx și exportul cache-ului Docker cu cache-to, în aceiași 10 GB
• Împărțirea testelor în sharduri, unde fiecare shard repetă setup-ul și minutele facturate cresc
• Sau propriul runner self-hosted: pregătirea mașinii, actualizările sistemului de operare, curățenia între joburi și repararea lui când cade

Fiecare dintre ele ocolește o mașină care uită totul. Skipbox păstrează mașina, așa că nu ai nevoie de niciuna.

Ce se schimbă pe Skipbox

Setup-ul rămâne pe disc. Joburile tale rulează pe mașina proprie a contului tău, iar ea rămâne între joburi. Imaginile Docker, layerele și cache-ul de build; cache-urile de pachete pentru npm, pip, Gradle și altele; instrumentele pe care le instalează setup-node și celelalte acțiuni setup. Cel puțin de 7× spațiul de cache de la GitHub, fără expirare după 7 zile și fără regula ramurilor.

Mașini mai mari la preț fix. Compilatoarele și runnerele de teste pornesc câte un worker pe nucleu, așa că mai multe nuclee scurtează pașii limitați de CPU.

Minutele sunt nelimitate pe toate planurile. Joburile Skipbox nu folosesc minute GitHub, așa că un buget GitHub nu le oprește niciodată.

Nicio mașină de îngrijit. Skipbox pregătește mașina, actualizează sistemul de operare și instrumentele, face curățenie după fiecare job, rulează o verificare a stării și reface o mașină care nu trece verificarea.

Mutarea înseamnă o singură linie

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

1. Conectează-te la Skipbox cu GitHub.
2. Instalează aplicația GitHub Skipbox și alege repository-urile.
3. Schimbă runs-on și fă push.

Ce instalează primul job e pe disc pentru al doilea.

Securitate

• Mașina este doar a contului tău. Niciun job al altei companii nu rulează pe ea.
• După fiecare job, credențialele runnerului, procesele și containerele sunt șterse. Din 13 noiembrie 2026, checkoutul și rezultatul buildului (target/ de la Cargo) rămân pe mașina ta pentru joburile următoare; „Curățare la fiecare job” îi dă fiecărui job o mașină nouă.
• Codul de la persoane fără acces de scriere (cum ar fi pull request-urile din forkuri) rulează pe o mașină nouă, de unică folosință.

Detaliile sunt în cum sunt izolate joburile.

Încearcă pe cel mai lent job

Perioada de probă este gratuită timp de 7 zile sau 3.000 de minute de job, oricare se termină mai întâi, și nu cere card. Mută cel mai lent job pe runs-on: skipbox, rulează-l de două ori la rând și pune duratele pașilor lângă cele de pe GitHub.

Actualizat pe 11 noiembrie 2026