GitHub Actions czy CircleCI? Minuta kosztuje podobnie, kolejka już nie

Przy standardowych zadaniach linuksowych GitHub Actions i CircleCI mają podobną cenę jednostkową, ale sam koszt pracy runnera nie rozstrzyga wyboru. Jeśli zadania napływają seriami, czas oczekiwania na ich start może mieć dla zespołu większe znaczenie niż niewielka różnica w rachunku. Przy spokojnym ruchu oraz krótkiej kolejce większą wagę zyskują opłaty za użytkowników, system runnera i przechowywane dane.

Porównanie istniejącego pipeline’u wymaga dwóch osobnych wyników: miesięcznego kosztu oraz czasu od zgłoszenia zmiany do otrzymania wyniku testów. Pierwszy zależy od sumy pracy wszystkich zadań; drugi także od ich zależności i oczekiwania na wolną pojemność. Dlatego pipeline z wieloma zadaniami równoległymi może szybko zwrócić wynik, a jednocześnie zużyć dużo płatnych minut.

Co właściwie trafia na rachunek

W rozliczeniu GitHub Actions plan Team obejmuje 3000 minut standardowych runnerów miesięcznie i 2 GB miejsca współdzielonego przez artefakty Actions oraz GitHub Packages. Po wykorzystaniu limitu standardowy Linux z dwoma rdzeniami kosztuje 0,006 USD za minutę, a macOS 0,062 USD. Minuty dotyczą pracy runnerów; magazyn artefaktów jest rozliczany osobno według zajętości narastającej w kolejnych godzinach miesiąca.

Cennik CircleCI przyznaje 30 000 bezpłatnych kredytów miesięcznie. Przy klasie Linux Medium zużywającej 10 kredytów na minutę odpowiada to 3000 minutom; reklamowane przez firmę 6000 minut w planie Free dotyczy tańszej klasy Docker Small. Plany Free i Performance obejmują po pięciu aktywnych użytkowników oraz 2 GB magazynu. Performance zaczyna się od zakupu kredytów za 15 USD, a dodatkowe kredyty są sprzedawane w blokach po 25 000; kredyty zużywają również dodatkowi użytkownicy i wybrane funkcje.

Analiza CostOps wylicza dla 50 ośmiominutowych buildów dziennie przez 22 dni po 8800 minut miesięcznie i po 34,80 USD nominalnej opłaty za obliczenia ponad pakiet na obu platformach. To przykład dla standardowego Linuksa, a nie porównanie całej faktury. GitHub Team dolicza stanowiska, natomiast CircleCI Performance rozlicza aktywnych użytkowników ponad pulę planu; zakup kredytów w blokach może też sprawić, że kwota zapłacona w danym miesiącu różni się od wartości kredytów już wykorzystanych.

Cztery profile do arkusza obciążenia

W każdym wierszu arkusza potrzebne są: liczba uruchomień, liczba zadań w pipeline’ie, system i klasa runnera, czas pracy zadania oraz liczba aktywnych użytkowników. Obliczenia to suma minut poszczególnych zadań, a nie liczba uruchomień pomnożona przez czas widoczny od początku do końca pipeline’u. Poniższe profile są warunkowymi przykładami; pokazują, które dane zmieniają wynik porównania.

• Mały pipeline linuksowy. Przyjmij 100 uruchomień miesięcznie, jedno ośmiominutowe zadanie w każdym i pięciu aktywnych użytkowników. Łączne zużycie wynosi 800 minut. Jeśli zadania korzystają ze standardowej klasy, dopłata za obliczenia może nie wystąpić. Istotne pozostają koszt planu, sposób liczenia użytkowników i zgodność obecnych zadań z nowym środowiskiem.
• Stały duży ruch. Przyjmij 50 uruchomień dziennie przez 22 dni robocze, po jednym zadaniu trwającym osiem minut, oraz ośmiu aktywnych użytkowników. Otrzymasz 8800 minut, czyli 5800 ponad pulę odpowiadającą standardowemu Linuksowi. W arkuszu trzy dodatkowe osoby w CircleCI powinny mieć osobny wiersz: połączenie ich kosztu ze stawką za minutę ukrywa różnicę między modelami rozliczeń.
• Szczyt równoległych zadań. Przyjmij 20 ośmiominutowych zadań gotowych do startu jednocześnie. Zużyją łącznie 160 minut pracy runnerów niezależnie od tego, czy ruszą razem, czy po kolei. Czas do wyniku może jednak znacząco się zmienić. Obok minut wpisz więc liczbę zadań, które faktycznie wystartowały równocześnie, oraz medianę i wysoki percentyl czasu oczekiwania.
• Buildy macOS i duże artefakty. Przyjmij 100 dwunastominutowych zadań macOS miesięcznie i osobną pulę testów linuksowych. Daje to 1200 minut macOS, których nie należy wyceniać stawką Linuksa. Dla artefaktów zapisz zarówno ilość danych, jak i czas ich przechowywania: plik usunięty po dniu obciąża magazyn inaczej niż plik utrzymywany przez cały miesiąc.

Profile można połączyć, gdy pipeline ma na przykład testy linuksowe i etap wydania na macOS. Wtedy każda klasa runnera zachowuje własny wiersz, a koszt magazynu i użytkowników jest dodawany dopiero do sumy. Ten podział pozwala zobaczyć, czy zmianę wyniku powodują minuty, liczba osób, spiętrzenie pracy czy dane zatrzymywane po buildzie.

Użytkownicy i macOS potrafią zmienić zwycięzcę

Przy dodatkowych użytkownikach znaczenie ma definicja osoby płatnej. CircleCI zalicza do aktywnych użytkowników osoby wprowadzające zmiany w kodzie projektu budowanego na platformie; GitHub Team jest rozliczany za stanowiska. Zespół z wieloma osobami mającymi dostęp do repozytorium, ale rzadko uruchamiającymi buildy, może więc uzyskać inny rachunek niż zespół o tej samej liczebności, w którym wszyscy regularnie dostarczają kod.

Lista stawek CircleCI podaje 200 kredytów za minutę dla macOS M4 Pro Medium oraz 25 000 kredytów miesięcznie za każdego dodatkowego użytkownika planu Performance. Przy cenie standardowych kredytów odpowiada to odpowiednio 0,120 USD za minutę i 15 USD za użytkownika. Stawki macOS nie są jednak testem szybkości: porównywane maszyny GitHub i CircleCI mają inne zasoby. Rzeczywisty koszt buildów macOS wynika z ceny właściwej klasy pomnożonej przez czas tego samego zadania zmierzony na każdej platformie.

Kolejka wpływa na czas wyniku, nie na sumę minut

W teście CircleCI na kodzie Reacta odtworzono 24 godziny commitów w szybkim tempie. Mediana oczekiwania na domyślnych runnerach GitHub Actions przekroczyła 153 sekundy, a maksymalny czas oczekiwania zadań CircleCI wyniósł 30,85 sekundy. Test wykonał jeden z porównywanych dostawców przy dużym, skupionym obciążeniu. Wynik pokazuje możliwą różnicę w takich warunkach, lecz nie określa czasu kolejki dla każdego zespołu i każdego planu.

Własny pomiar powinien oddzielać trzy odcinki: oczekiwanie na start, wykonywanie zadań oraz czas potrzebny na ukończenie zależnych etapów. Przy dwudziestu zadaniach gotowych jednocześnie krótsza kolejka może przyspieszyć odpowiedź dla programisty bez zmniejszenia łącznej liczby płatnych minut. Jeśli testy blokują połączenie zmian, wysoki percentyl czasu do wyniku bywa bardziej użyteczny niż średnia z całego miesiąca, która miesza spokojne godziny ze szczytami.

Takie porównanie ma sens tylko dla podobnej konfiguracji: tej samej wersji testów, porównywalnej klasy maszyny i zbliżonej liczby jednoczesnych uruchomień. Inaczej różnica może pochodzić z pamięci runnera, podziału testów lub zależności między zadaniami. Przy migracji liczy się czas całego pipeline’u, ponieważ szybszy start pojedynczego zadania nie pomoże, jeśli późniejszy etap pozostaje wąskim gardłem.

Artefakty domykają koszt migracji

Magazynu nie da się rzetelnie oszacować samym rozmiarem ostatniego artefaktu. Znaczenie mają częstotliwość tworzenia plików, okres ich zatrzymania, pamięć podręczna i inne dane współdzielące limit. W GitHub Actions usunięcie artefaktu zatrzymuje dalsze naliczanie jego miejsca, ale nie cofa zużycia już zgromadzonego w bieżącym cyklu. CircleCI pobiera kredyty za wykorzystanie magazynu ponad limit planu i za część funkcji dodatkowych, więc sama liczba buildów nie opisuje pełnego zużycia.

Decyzję o migracji najlepiej oprzeć na dwóch wartościach z tego samego okresu: całkowitym koszcie uwzględniającym plan, obliczenia, użytkowników i dane oraz czasie do wyniku w zwykłych godzinach i podczas szczytu. Gdy oba warianty mają podobny koszt standardowego Linuksa, przewagę może dać mniejsza kolejka. Przy dużym udziale macOS albo wielu dodatkowych użytkownikach rachunek może wskazać przeciwny kierunek, nawet jeśli zadania startują szybciej.

Przeczytaj także:

• Lokalny model czy API? Oszczędność znika przy złym wykorzystaniu
• Dane do ChatGPT trzeba najpierw odchudzić — samo usunięcie nazw nie wystarczy
• Pinecone czy pgvector? Filtry potrafią zmienić zwycięzcę