Tanie i szybkie
Runnery GitHub Actions
Bez limitu, w stałej cenie

Tak, większość. Skipbox uruchamia workflowy z repozytoriów publicznych i prywatnych w organizacjach i na kontach osobistych na GitHubie. VM to Ubuntu 24.04 na x64 z Dockerem, gitem, build-essential, Node 22 i Pythonem 3.12, a zadanie działa jako użytkownik z sudo bez hasła, tak jak na runnerach GitHuba. Obraz ubuntu-latest GitHuba ma więcej preinstalowanych narzędzi, więc do innych narzędzi dodaj actions/setup-java, actions/setup-go i podobne.

Odkąd AI pisze coraz więcej kodu, CI działa co miesiąc coraz więcej, a rozliczenie za minutę rośnie z każdym uruchomieniem. Dlatego Skipbox celowo wybrał inny model: wynajmujesz na miesiąc VM tylko dla swojego konta. GitHub nie nalicza opłat za minuty runnerów self-hosted, więc niezależnie od liczby zadań cena pozostaje stała: $39 miesięcznie za S. Fluxenic, firma stojąca za Skipbox, korzysta z serwerów tanich dostawców chmury i z własnych, a udostępnia je jako VM w praktycznym rozmiarze. Skipbox robi za Ciebie żmudną część: rejestruje runnery, sprząta po każdym zadaniu i sprawdza stan maszyny. Odbudowuje też uszkodzoną maszynę i aktualizuje obraz. Przy pełnym wykorzystaniu cena to 1/12 ceny GitHuba i 1/8 ceny Blacksmith.

Bo maszyna należy tylko do Twojego konta i działa dalej między zadaniami. Warstwy Dockera i cache pakietów z poprzedniego zadania wciąż są na jej dysku, więc build, który z nich korzysta, nie musi ich pobierać ani budować od nowa. Zadanie na runnerze hostowanym przez GitHub za każdym razem startuje na nowej VM z pustym dyskiem. Nawet S trzyma cache na własnym dysku 80 GB. To ponad 7x więcej cache, niż GitHub domyślnie daje repozytorium, i nic w nim nie wygasa po 7 dniach nieużywania. S ma też 4 vCPU, więcej niż 2 rdzenie ubuntu-latest w repozytorium prywatnym.

Nawet jeśli wynajmiesz VPS tej samej wielkości u dużego dostawcy, nie dostaniesz runnera self-hosted, który byłby tańszy, szybszy i wymagał mniej pracy niż Skipbox. Skipbox rejestruje nowy runner dla każdego zadania i potem go usuwa. Po każdym zadaniu czyści dane uwierzytelniające runnera i zachowuje Twój checkout oraz wynik buildu dla następnego. Sprawdza stan maszyny, odbudowuje ją, gdy kontrola się nie powiedzie, i aktualizuje obraz. Kod od osób bez uprawnień do zapisu (na przykład pull requesty z forków) działa na jednorazowej VM. Wszystko to dostajesz za $39 miesięcznie w planie S, zmieniając jedną linię runs-on, bez niczego do utrzymywania.

Tak, repozytoria publiczne i prywatne tak samo. Kod od osób bez uprawnień do zapisu (na przykład pull requesty z forków) działa na nowej VM, która czyta Twój cache, ale nie może go zmienić; Twoja własna maszyna uruchamia tylko kod Twojego zespołu.

Tak. Plany kosztują $39, $79 lub $149 miesięcznie, płatne w dolarach amerykańskich co miesiąc albo z góry za rok w cenie 10 miesięcy, bez opłat za użycie. Plan ogranicza liczbę zadań działających naraz i ich wielkość, a nie minuty: zadanie, które się nie mieści, czeka, aż skończy się któreś z działających, a czekanie nic nie dodaje do rachunku. Strona Twojej organizacji w Skipbox pokazuje, ile zadań czeka i jak długo czeka najstarsze z nich. Zadanie może działać maksymalnie 6 godzin.

Równoległe zadania liczymy w zadaniach 4 vCPU. Plan uruchamia naraz zadania do swojej łącznej liczby vCPU (S 4, M 8, L 16 vCPU), więc zadanie na 8 vCPU liczy się jako 2, a na 16 vCPU jako 4. Największe pojedyncze zadanie, jakie plan może uruchomić, ma tyle vCPU, ile plan: 4 w S, 8 w M, 16 w L. Dodaj plany, aby uruchamiać więcej zadań naraz.

Każde zadanie w Skipbox S dostaje 4 vCPU i 16 GB; ubuntu-latest GitHuba w repozytorium prywatnym to 2 rdzenie i 8 GB. Twoja własna maszyna zachowuje też warstwy Dockera i cache pakietów z poprzedniego zadania, więc build, który z nich korzysta, nie pobiera ich ponownie; zadanie na runnerze hostowanym przez GitHub za każdym razem startuje na nowej VM. docker build i docker compose build ponownie używają warstw. Domyślny builder docker/setup-buildx-action w każdym zadaniu startuje pusty, więc ustaw w nim driver: docker, aby korzystać z cache maszyny. Gdy Twoje pierwsze zadanie zadziała w Skipbox, panel pokaże jego czas obok mediany na GitHubie z ostatnich 30 dni, jeśli GitHub je wtedy uruchamiał.

16 GB w planie S, na własnej maszynie: 2× więcej niż 8 GB ubuntu-latest w repozytorium prywatnym i tyle samo, co w „larger runner” GitHuba z 4 rdzeniami. Plan S miał dawniej 8 GB i to nie wystarczało dla openai/codex (rust-v0.159.3): cargo clippy --workspace --tests kończyło się tylko dzięki przeniesieniu około 14 GB do skompresowanego swapu. Przy dzisiejszych 16 GB ten sam build przenosi do swapu około 20 MB. Dla zadania, które potrzebuje więcej, plan L ma 32 GB.

Tylko do tego, czego potrzebuje, aby rejestrować runnery i sprawdzać zadania. W organizacji aplikacja Skipbox CI prosi o trzy uprawnienia: Self-hosted runners (zapis), aby dla każdego zadania zarejestrować runner w GitHubie i usunąć go po zakończeniu zadania; Actions (odczyt i zapis), aby widzieć, które zadania czekają, sprawdzać ich status, odczytać, jak długo działały Twoje zadania w ostatnich 30 dniach na potrzeby wyceny, i ponownie uruchomić zadanie, którego maszyna Skipbox zatrzymała się w trakcie; oraz Metadata (odczyt). Aplikacja Skipbox CI nigdy nie edytuje ani nie pushuje Twoich workflowów i nie może czytać Twojego kodu: każde zadanie samo pobiera kod na VM, na której działa. Na koncie osobistym GitHub rejestruje runner dla repozytorium tylko z uprawnieniem Administration, które obejmuje też ustawienia repozytorium, współpracowników i klucze wdrożeniowe. Skipbox (personal) prosi o nie i używa go tylko do rejestrowania i usuwania runnerów. Wyjątkiem jest jedna funkcja, i to tylko wtedy, gdy ją zainstalujesz: przycisk „Otwórz pull request” w panelu korzysta z osobnej aplikacji Skipbox Migrate, którą instalujesz tylko w wybranych repozytoriach. Tam prosi o zapis do Contents, Workflows i Pull requests, pushuje jedną gałąź (skipbox/run-ci-on-skipbox), która zmienia tylko linie runs-on, i otwiera z niej pull request. Nigdy nie scala ani nie rusza gałęzi domyślnej. Przy logowaniu Skipbox odczytuje też Twój adres e-mail, aby wysyłać powiadomienia o okresie próbnym i rozliczeniach. Jak na każdym runnerze, VM zadania ma sekrety Twojego workflowu i token GitHuba dla tego zadania, więc kod uruchamiany przez zadanie może je odczytać.

Na własnej maszynie Twojej organizacji: VM w rozmiarze Twojego planu (także w okresie próbnym), o jedną więcej z każdym dodatkowym planem. Nie korzysta z niej żadna inna organizacja. Działa dalej między Twoimi zadaniami, więc obrazy Dockera, cache, checkout i wynik buildu (target/ Cargo oraz cache Turborepo przy turbo 2) zostają dla kolejnych zadań. Działa na serwerach, które Fluxenic, firma stojąca za Skipbox, wynajmuje od dostawców chmury lub utrzymuje sama. Polityka prywatności wymienia każdego dostawcę i kraj. Po każdym zadaniu czyszczone są dane uwierzytelniające runnera, dane uwierzytelniające gita w checkoucie i typowe pliki z danymi uwierzytelniającymi. Zadania ponad Twoje własne maszyny, kod od osób bez uprawnień do zapisu (na przykład pull requesty z forków) i każde zadanie przy włączonej opcji Nowa VM dla każdego zadania działają na nowej VM, usuwanej razem z dyskiem po zakończeniu zadania. Zadanie, które wciąż działa po 6 godzinach, jest zatrzymywane. Z internetu nie da się połączyć do maszyny. Wychodząca poczta (port TCP 25) jest zablokowana. Reszta internetu jest otwarta, tak jak na runnerach hostowanych przez GitHub. Ruch nie jest płatny.

Tak. W dowolnej chwili naciśnij Zresetuj maszynę na stronie Plany i płatności. Włącz tam opcję Nowa VM dla każdego zadania, a każde zadanie będzie działać na nowej VM.

Anulujesz w każdej chwili; plan działa do końca opłaconego miesiąca albo roku. Jeśli Twoje zadania nie są w Skipbox szybsze niż były na GitHubie, odzyskasz wszystko, co zapłaciłeś, zarówno w planach miesięcznych, jak i rocznych: poproś o to na stronie Plany i płatności swojego konta w ciągu 30 dni od pierwszej płatności. Skipbox bierze medianę czasu każdego zadania w Skipbox i na GitHubie (30 dni przed instalacją Skipbox), waży każde zadanie tym, jak często działało na GitHubie, i porównuje obie sumy; zadanie się liczy, gdy uruchomiło się co najmniej 3 razy w każdym z nich, a bez zadania do porównania nie ma czego zwracać. Jeśli pierwsze zadanie uruchomione po wykupieniu planu nie wystartuje w ciągu 10 minut, nie licząc czasu czekania za Twoimi własnymi zadaniami, automatycznie zwrócimy całą płatność i zakończymy plan. Poza tym opłacony miesiąc ani rok nie podlega zwrotowi, z wyjątkiem przypadków wymienionych w Warunkach.

Nic nie jest pobierane: okres próbny nie wymaga karty. Zaczyna się przy pierwszym zadaniu w Skipbox, a nie przy logowaniu czy instalacji aplikacji, i uruchamia jedno zadanie 4 vCPU · 16 GB naraz przez 7 dni lub 3000 minut, zależnie od tego, co nastąpi wcześniej. Limit okresów próbnych: 1 na konto i 1 na osobę. Po jego zakończeniu nowe zadania czekają na GitHubie, dopóki nie wybierzesz planu.

Zmień runs-on na skipbox, aby przejść, i z powrotem na ubuntu-latest, aby wrócić. Zaloguj się przez GitHub, zainstaluj aplikację Skipbox CI w organizacji albo Skipbox (personal) na koncie osobistym, zmień linię runs-on zadania na skipbox i zrób commit; aby dostać większą VM w planach, które ją obejmują, użyj skipbox-8x16 lub skipbox-16x32. Aby wrócić, zmień runs-on: skipbox z powrotem na runs-on: ubuntu-latest. Nic innego w repozytorium się nie zmieniło.