Workflow-urile mele vor rula fără modificări?
Da, majoritatea. Skipbox rulează workflow-urile repository-urilor publice și private din organizații GitHub și conturi personale. VM-ul este Ubuntu 24.04 pe x64, cu Docker, git, build-essential, Node 22 și Python 3.12, iar jobul rulează ca un utilizator cu sudo fără parolă, ca pe runnerele GitHub. Imaginea ubuntu-latest a GitHub are mai multe instrumente preinstalate, așa că adaugă actions/setup-java, actions/setup-go și altele asemenea pentru restul.
De ce este atât de ieftin?
Pe măsură ce AI-ul scrie tot mai mult cod, CI-ul rulează tot mai mult în fiecare lună, iar facturarea la minut crește cu fiecare rulare. De aceea Skipbox a ales intenționat alt model: închiriezi lunar un VM doar pentru contul tău. GitHub nu facturează minutele runnerelor self-hosted, așa că oricâte joburi rulezi, prețul rămâne fix: $39 pe lună pentru S. Fluxenic, compania din spatele Skipbox, operează servere de la furnizori cloud ieftini și servere proprii și le oferă ca VM-uri de o mărime utilă. Skipbox face partea plictisitoare în locul tău: înregistrează runnerele, curăță după fiecare job și verifică starea mașinii. De asemenea, reface o mașină stricată și ține imaginea la zi. La utilizare maximă, prețul este 1/12 din cel al GitHub și 1/8 din cel al Blacksmith.
De ce este atât de rapid?
Pentru că mașina este doar a contului tău și rămâne pornită între joburi. Layerele Docker și cache-urile de pachete de la ultimul job sunt încă pe discul ei, așa că un build care le folosește nu le mai descarcă și nu le mai reconstruiește. Un job pe un runner găzduit de GitHub pornește de fiecare dată pe un VM nou, cu discul gol. Chiar și S își păstrează cache-urile pe propriul disc de 80 GB. Asta înseamnă de peste 7x mai mult decât cache-ul pe care GitHub îl dă implicit unui repository, iar nimic din el nu expiră după 7 zile de nefolosire. S are și 4 vCPU, mai mult decât cele 2 nuclee ale ubuntu-latest pe un repository privat.
N-ar costa mai puțin să închiriez propriul VPS ca runner?
Închiriază un VPS de aceeași mărime de la un furnizor mare și tot nu vei avea un runner self-hosted mai ieftin, mai rapid și care să-ți dea mai puțină muncă decât Skipbox. Skipbox înregistrează un runner nou pentru fiecare job și îl elimină după aceea. După fiecare job, șterge credențialele runnerului și păstrează checkoutul și rezultatul buildului pentru următorul. Verifică starea mașinii, o reface când verificarea eșuează și ține imaginea la zi. Codul de la persoane fără drept de scriere (de exemplu, pull request-urile din forkuri) rulează pe un VM de unică folosință. Toate acestea le ai pentru $39 pe lună pe S, schimbând o singură linie runs-on, fără nimic de întreținut.
Skipbox rulează și repository-uri publice?
Da, atât repository-uri publice, cât și private. Codul de la persoane fără drept de scriere (de exemplu, pull request-urile din forkuri) rulează pe un VM nou, care citește cache-urile tale, dar nu le poate modifica; mașina ta dedicată rulează doar codul echipei tale.
Minutele sunt chiar nelimitate?
Da. Planurile costă $39, $79 sau $149 pe lună, facturate în dolari americani lunar sau anual în avans, la prețul a 10 luni, fără taxe de utilizare. Un plan limitează câte joburi rulează simultan și cât de mare e fiecare, nu minutele: un job care nu încape așteaptă până se termină unul aflat în rulare, iar așteptarea nu adaugă nimic la factură. Pagina organizației tale din Skipbox arată câte joburi așteaptă și de cât timp așteaptă cel mai vechi. Un job poate rula cel mult 6 ore.
Cum se numără joburile mai mari la joburile simultane?
Joburile simultane se numără în joburi de 4 vCPU. Un plan rulează simultan joburi până la totalul său de vCPU (S 4, M 8, L 16 vCPU), așa că un job de 8 vCPU contează cât 2, iar unul de 16 vCPU cât 4. Cel mai mare job pe care îl poate rula un plan are atâtea vCPU cât are planul: 4 pe S, 8 pe M, 16 pe L. Adaugă planuri ca să rulezi mai multe joburi simultan.
Cum se compară Skipbox cu runnerele GitHub?
Fiecare job pe Skipbox S primește 4 vCPU și 16 GB; ubuntu-latest de la GitHub pe un repository privat are 2 nuclee și 8 GB. Mașina ta dedicată păstrează și layerele Docker și cache-urile de pachete de la ultimul job, așa că un build care le folosește nu le mai descarcă; un job pe un runner găzduit de GitHub pornește de fiecare dată pe un VM nou. docker build și docker compose build refolosesc layerele. Builderul implicit din docker/setup-buildx-action pornește gol la fiecare job, așa că setează-i driver: docker ca să folosească cache-ul mașinii. După ce primul tău job rulează pe Skipbox, panoul de control arată timpul lui lângă mediana lui pe GitHub din ultimele 30 de zile, dacă GitHub l-a rulat în acea perioadă.
Buildul meu rămâne fără memorie pe runnerul GitHub. Câtă memorie are Skipbox?
16 GB pe planul S, pe mașina ta dedicată: de 2× mai mult decât cei 8 GB ai ubuntu-latest pe un repository privat și la fel ca „larger runner” de la GitHub, cel cu 4 nuclee. Planul S avea înainte 8 GB, iar asta nu a ajuns pentru openai/codex (rust-v0.159.3): cargo clippy --workspace --tests s-a terminat doar după ce aproximativ 14 GB au fost mutați în swap comprimat. Cu cei 16 GB de azi, același build pune în swap aproximativ 20 MB. Pentru un job care are nevoie de mai mult, planul L are 32 GB.
La ce are acces Skipbox?
Doar la ce îi trebuie ca să înregistreze runnere și să verifice joburile. Pe o organizație, aplicația Skipbox CI cere trei permisiuni: Self-hosted runners (scriere), ca să înregistreze la GitHub un runner pentru fiecare job și să-l elimine când jobul se termină; Actions (citire și scriere), ca să vadă ce joburi așteaptă, să le verifice starea, să citească cât au rulat joburile tale în ultimele 30 de zile pentru oferta ta și să ruleze din nou un job a cărui mașină Skipbox s-a oprit în timpul jobului; și Metadata (citire). Aplicația Skipbox CI nu editează și nu face push la workflow-urile tale și nu îți poate citi codul: fiecare job își face singur checkout la cod, pe VM-ul pe care rulează. Pe un cont personal, GitHub înregistrează un runner pentru un repository doar cu permisiunea Administration, care acoperă și setările repository-ului, colaboratorii și cheile de deploy. Skipbox (personal) o cere și o folosește doar ca să înregistreze și să elimine runnere. O singură funcție face excepție, și doar dacă o instalezi: butonul „Deschide un pull request” din panoul de control folosește o aplicație separată, Skipbox Migrate, pe care o instalezi doar pe repository-urile pe care le alegi. Acolo cere drept de scriere pentru Contents, Workflows și Pull requests, face push la o singură ramură (skipbox/run-ci-on-skipbox) care schimbă doar linii runs-on și deschide un pull request din ea. Nu face niciodată merge și nu atinge ramura implicită. Când te conectezi, Skipbox citește și adresa ta de e-mail, pentru notificările despre perioada de probă și facturare. Ca pe orice runner, VM-ul unui job conține secretele workflow-ului tău și tokenul GitHub pentru acel job, așa că le poate citi codul pe care îl rulează jobul.
Unde rulează joburile?
Pe mașina dedicată a organizației tale: un VM de mărimea planului tău (și în perioada de probă), încă unul pentru fiecare plan în plus. Nicio altă organizație nu îl folosește. Rămâne pornit între joburi, așa că imaginile Docker, cache-urile, checkoutul și rezultatul buildului (target/ de la Cargo și, cu turbo 2, cache-ul Turborepo) rămân pentru joburile următoare. Rulează pe servere pe care Fluxenic, compania din spatele Skipbox, le închiriază de la furnizori cloud sau le operează singură. Politica de confidențialitate enumeră fiecare furnizor și țară. După fiecare job se șterg credențialele runnerului, credențialele git din checkout și fișierele obișnuite cu credențiale. Joburile care depășesc mașinile tale dedicate, codul de la persoane fără drept de scriere (de exemplu, pull request-urile din forkuri) și toate joburile cu „Curățare la fiecare job” rulează pe un VM nou, șters împreună cu discul când se termină jobul. Un job care încă rulează după 6 ore este oprit. Nimic nu se poate conecta din internet. E-mailul trimis în afară (portul TCP 25) este blocat. Restul internetului este deschis, ca pe runnerele găzduite de GitHub. Traficul nu se taxează.
Pot reporni mașina de la zero sau pot rula fiecare job pe un VM nou?
Da. Apasă „Resetează mașina” în Planuri și facturare, oricând. Activează acolo „Curățare la fiecare job”, iar fiecare job va rula pe un VM nou.
Putem anula sau primi banii înapoi?
Anulezi oricând; planul rulează până la finalul lunii sau al anului plătit. Dacă joburile tale nu sunt mai rapide pe Skipbox decât erau pe GitHub, primești înapoi tot ce ai plătit, la fel pe planurile lunare și pe cele anuale: cere asta din pagina Planuri și facturare a contului tău, în cel mult 30 de zile de la prima plată. Skipbox ia timpul median al fiecărui job pe Skipbox și pe GitHub (în cele 30 de zile dinainte să instalezi Skipbox), ponderează fiecare job după cât de des a rulat pe GitHub și compară cele două totaluri; un job contează după ce a rulat de cel puțin 3 ori pe fiecare, iar fără niciun job de comparat nu există nimic de rambursat. Dacă primul job pe care îl rulezi după abonare nu pornește în 10 minute, fără timpul în care așteaptă după propriile tale joburi, îți rambursăm automat toată plata și încheiem planul. În rest, o lună sau un an plătit nu se rambursează, cu excepția cazurilor enumerate în Termeni și condiții.
Ce se întâmplă când se termină perioada de probă? Plătesc ceva?
Nu plătești nimic: perioada de probă nu cere card. Începe la primul tău job pe Skipbox, nu când te conectezi sau instalezi aplicația, și rulează câte un job 4 vCPU · 16 GB o dată, timp de 7 zile sau 3.000 de minute, oricare se termină primul. Există 1 perioadă de probă per cont și 1 per persoană. Când se termină, joburile noi așteaptă pe GitHub până alegi un plan.
Cum rulez un job pe Skipbox și cum revin?
Schimbă runs-on în skipbox ca să treci pe Skipbox și înapoi în ubuntu-latest ca să revii. Conectează-te cu GitHub, instalează aplicația Skipbox CI pe organizația ta sau Skipbox (personal) pe contul tău personal, schimbă linia runs-on a jobului în skipbox și fă commit; pentru un VM mai mare, pe planurile care îl includ, folosește skipbox-8x16 sau skipbox-16x32. Ca să revii, schimbă runs-on: skipbox înapoi în runs-on: ubuntu-latest. Nimic altceva din repository nu s-a schimbat.