Narzędzie GitHuba do przenoszenia potoków z Jenkinsa samo wypisuje, czego nie przeniesie: między innymi obowiązkowych narzędzi budujących, potoków pisanych skryptem, sekretów, własnych maszyn wykonawczych i nieznanych wtyczek. To nie jest przypis w dokumentacji, tylko rachunek za migrację wystawiony przez samego dostawcę. Narzędzie automatyzuje część roboty i samo wypisuje raport tego, co zostaje do zrobienia ręcznie. Zestawienia Jenkins vs GitHub Actions kończą się tymczasem zwykle na tabelce z funkcjami. Poniżej idziemy w drugą stronę i liczymy to, czego w tabelkach nie ma.
Dwa narzędzia, dwa zupełnie różne modele własności
Jenkins to program, który uruchamiasz u siebie. Dostajesz serwer z interfejsem, do niego doklejasz wtyczki, a całość musi gdzieś stać i ktoś musi ją aktualizować. W zamian nie pytasz nikogo o zgodę i nie płacisz za minutę pracy.
GitHub Actions działa odwrotnie. Jest częścią serwisu, w którym i tak trzymasz kod. W wariancie chmurowym nie stawiasz serwera sterującego ani nie aktualizujesz wtyczek, choć nadal możesz podłączyć własne maszyny wykonawcze. W zamian płacisz za czas pracy maszyn GitHuba po przekroczeniu limitu planu i akceptujesz cudze reguły gry.
Ta różnica nie jest techniczna, tylko organizacyjna. Jenkins przenosi koszt na czas twoich ludzi. Actions może przenieść jego część na fakturę. Pierwszy wariant wygląda taniej dopóty, dopóki nikt nie liczy godzin spędzonych na utrzymaniu.
Warto od razu odrzucić jedno uproszczenie. Actions nie jest młodszą wersją Jenkinsa i nie zastępuje go funkcja po funkcji. To inny model pracy, w którym opis potoku mieszka w repozytorium razem z kodem i podlega tym samym regułom przeglądu.
Rachunek za Jenkinsa, którego nie ma w cenniku
Jenkins jest darmowy w sensie licencji i to prawda. Reszta kosztów jest jednak realna i warto je nazwać po kolei. Pierwszy to maszyna, na której serwer stoi, razem z kopią zapasową i miejscem na pliki wynikowe z budowania.
Drugi to wtyczki. Katalog projektu zawiera ponad dwa tysiące wtyczek tworzonych przez społeczność, a dojrzała instalacja potrafi korzystać z wielu z nich naraz. Każda z nich to osobny projekt z własnym tempem rozwoju, własnymi błędami i własnymi ogłoszeniami o lukach. Aktualizacja jednej potrafi popsuć drugą, a odpowiedzialność za sprawdzenie tego jest po twojej stronie.
Trzeci koszt jest cykliczny i najłatwiej go przegapić. Jenkins chodzi na Javie i wymagania tej Javy rosną. Wydanie długoterminowe 2.555.1 z kwietnia 2026 przestało wspierać Javę 17, a od tej pory potrzebna jest Java 21 albo 25. Dla firmy oznacza to zaplanowaną pracę, której nikt nie zamawiał i która nie dodaje żadnej funkcji.
Czwarty koszt jest najbardziej podstępny, bo nie widać go w żadnym zestawieniu. To wiedza o tym, dlaczego wasz Jenkins jest skonfigurowany tak, a nie inaczej. W starszych instalacjach bywa ona skupiona w niewielkiej części zespołu.
Rachunek za GitHub Actions, którego nie widać w minutach
Po drugiej stronie liczby są jawne i łatwe do sprawdzenia, ale też łatwe do źle zrozumienia. Konta bezpłatne dostają 2000 minut miesięcznie dla repozytoriów prywatnych, plany Pro i Team po 3000, a GitHub Enterprise Cloud 50 000. Repozytoria publiczne korzystają ze standardowych maszyn bezpłatnie.
Powyżej limitu płaci się za minutę i tu zaczyna się rzecz, o której warto wiedzieć wcześniej. Minuta na bazowej dwurdzeniowej maszynie x64 kosztuje 0,006 dolara na Linuksie, 0,010 na Windowsie i 0,062 na macOS. Stawka dla macOS to nieco ponad dziesięciokrotność stawki linuksowej. Zespół budujący aplikację mobilną na Apple zobaczy więc zupełnie inny rachunek niż zespół budujący usługę internetową, przy identycznej liczbie uruchomień.
Ceny maszyn GitHuba spadły zresztą 1 stycznia 2026, według producenta nawet o 39%, przy niezmienionych limitach bezpłatnych. Ta sama zapowiedź przewidywała też opłatę za minuty na własnych maszynach od marca 2026. GitHub odłożył tę zmianę po opiniach użytkowników, a dokumentacja rozliczeń nadal podaje użycie własnych maszyn jako bezpłatne. Odłożenie to jednak nie to samo co rezygnacja.
Prawdziwy koszt Actions leży gdzie indziej niż w minutach. Twoje potoki zostają zapisane w formacie tego dostawcy, a część kroków korzysta z gotowych elementów napisanych przez osoby trzecie. To wygoda, za którą płaci się zależnością.
Czego narzędzie migracyjne nie przeniesie za ciebie
GitHub wskazuje pięć typowych grup wymagających pracy ręcznej: obowiązkowe narzędzia budujące, potoki pisane skryptem, sekrety, własne maszyny wykonawcze i nieznane wtyczki. Importer przejrzy serwer Jenkinsa, spróbuje przekonwertować potoki i wskaże w raporcie pozostałe nieobsługiwane elementy. To nie jest zamknięta lista, tylko punkt wyjścia do wyceny.
Najcięższa pozycja z tej listy to potoki pisane skryptem. Jeżeli wasze pliki opisujące budowanie zawierają pętle, warunki i własne funkcje, zamiana wymaga przepisania logiki ręcznie. To zwykle najstarsze i najważniejsze potoki w firmie.
Druga pozycja to nieznane wtyczki, czyli takie, dla których nie ma gotowego odpowiednika. Im dłużej stoi wasz Jenkins, tym więcej ich będzie. Każda wymaga decyzji: znaleźć zamiennik, napisać własny krok albo zrezygnować z funkcji.
Trzecia to sekrety i własne maszyny wykonawcze. Hasła i klucze trzeba przenieść ręcznie, bo żadne narzędzie nie ma do nich dostępu. Własne maszyny trzeba skonfigurować od nowa, choć akurat tutaj Actions pozwala ich używać dalej i nie liczy za nie minut. Czwarta pozycja to obowiązkowe narzędzia budujące, czyli kompilatory i pakiety, które na waszym Jenkinsie ktoś kiedyś zainstalował ręcznie. Na maszynie GitHuba trzeba je zainstalować krokiem w potoku albo przygotować własny obraz.
Realistyczna kolejność jest więc taka. Narzędzie robi szybką część i pokazuje skalę roboty. Trudna część to przepisanie kilku najstarszych potoków i decyzje o wtyczkach. Na tę drugą część warto zarezerwować czas w planie, a nie liczyć, że zmieści się obok bieżących zadań.
Gdzie Jenkins nadal wygrywa
Jenkins wygrywa wtedy, gdy budowanie jest przywiązane do sprzętu, sieci albo repozytorium poza GitHubem. Pierwsza z tych sytuacji to sprzęt. Jeżeli budowanie wymaga konkretnej maszyny, konkretnego urządzenia podłączonego kablem albo licencjonowanego oprogramowania przypisanego do stanowiska, własny serwer jest naturalnym miejscem.
Druga to sieć odcięta od internetu. W bankowości, przemyśle i administracji zdarza się wymóg, żeby budowanie kodu odbywało się bez połączenia z zewnętrzną usługą. Actions ma wariant serwerowy, ale to osobny produkt dla dużych organizacji i osobna rozmowa handlowa.
Trzecia to kod trzymany poza GitHubem. Actions działa najlepiej z repozytoriami na GitHubie i tam ma sens. Firma z kodem na własnym serwerze musiałaby przenieść najpierw repozytoria, a to zupełnie inna decyzja niż zmiana narzędzia do budowania. Rozkładamy ją w tekście o tym, którą platformę wybrać: GitLab czy GitHub. Jeżeli kod leży na GitLabie, realne porównanie prowadzi zresztą gdzie indziej, bo wbudowany system budowania jest już na miejscu – zestawiamy je w tekście GitHub Actions vs GitLab CI.
Czwarta jest najbardziej ludzka. Jeżeli Jenkins działa, ktoś go rozumie i nikt na niego nie narzeka, migracja jest projektem bez odbiorcy. Koszt poniesiecie na pewno, a korzyść jest hipotetyczna.
Jak wygląda rozsądna kolejność przejścia
Migrację prowadzi się równolegle, a nie skokowo: stary serwer pracuje dalej, dopóki nowe potoki nie przejdą pełnego cyklu budowania i wdrożenia. Najgorszy możliwy plan to przeniesienie wszystkiego naraz i wyłączenie Jenkinsa w jeden weekend.
Zacznij od nowych projektów. Każdy nowy serwis dostaje potok w Actions od pierwszego dnia i nikt nie dokłada niczego do Jenkinsa. Po kilku takich projektach masz realne porównanie na własnym kodzie, a nie na cudzych tabelkach.
Potem weź jeden istniejący potok o średnim znaczeniu i przenieś go do końca, razem z sekretami i wdrożeniem. To ćwiczenie pokaże wszystkie braki w waszej konkretnej konfiguracji. Dopiero po nim da się oszacować resztę z jakąkolwiek sensownością.
Własne maszyny wykonawcze są przy tym dobrym mostem i szkoda z nich nie skorzystać. Pozwalają uruchamiać zadania na waszym sprzęcie, w waszej sieci, ale sterować nimi z poziomu repozytorium. Dzięki temu część argumentów za zostaniem przy Jenkinsie znika bez utraty kontroli nad sprzętem. Warto też sprawdzić, jak dużo waszych potoków i tak stoi już na kontenerach, bo to najłatwiejsze do przeniesienia kawałki, co tłumaczymy przy porównaniu kontenera z maszyną wirtualną.
Frontend Master 2026 · Kodożercy
Frontend dla osób, które chcą pisać kod, nie tylko prompty
Frontend Master 2026 to pakiet, który daje Ci fundamenty potrzebne w pierwszej pracy frontendowej. HTML, CSS, JavaScript, Git – polskie wideo, projekty, ścieżka od początku do deploy.
Zobacz program kursów →
Najczęstsze pytania
Czy GitHub Actions może zastąpić Jenkinsa w każdej firmie?
Nie w każdej. Przeszkodą bywa kod trzymany poza GitHubem, wymóg pracy w sieci odciętej od internetu albo budowanie wymagające konkretnego sprzętu. W pozostałych przypadkach zwykle może, ale przeniesienie starych potoków pisanych skryptem to praca ręczna, nie zamiana narzędzia.
Ile realnie kosztuje GitHub Actions dla małego zespołu?
Przy repozytoriach publicznych standardowe maszyny są bezpłatne. Przy prywatnych liczy się plan i system operacyjny maszyny: konto bezpłatne ma 2000 minut miesięcznie, a minuta ponad limit na bazowej dwurdzeniowej maszynie kosztuje od 0,006 dolara na Linuksie do 0,062 na macOS. Zaskoczeniem bywają budowania aplikacji na Apple, gdzie rachunek rośnie ponad dziesięciokrotnie.
Czy warto utrzymywać Jenkinsa równolegle z Actions?
Przez czas migracji tak, i to jest najbezpieczniejszy wariant. Na stałe rzadko, bo utrzymujecie wtedy dwa systemy naraz, a przy wyjściu poza darmowy limit dochodzą jeszcze opłaty za minuty. Wyjątkiem są firmy, w których część budowania musi zostać na własnym sprzęcie z powodów formalnych.
Czy własne maszyny w GitHub Actions są bezpłatne?
Według aktualnej dokumentacji rozliczeń tak, użycie własnych maszyn nie zużywa minut. W grudniu 2025 zapowiedziano opłatę za takie minuty od marca 2026, ale GitHub odłożył tę zmianę po opiniach użytkowników. Odłożenie nie jest rezygnacją, więc przy planowaniu na lata warto założyć, że temat może wrócić.
{ aplikacje webowe }Masz pomysł na aplikację? Najpierw go zobacz
Zanim zainwestujesz w pełny system, przygotujemy klikalny prototyp, który pokażesz zespołowi albo klientom. Potem budujemy aplikację webową, która rośnie razem z firmą.
Podsumowanie
Jenkins nie ma ceny, tylko koszt, i ten koszt rośnie razem z wiekiem instalacji: serwer, wtyczki z własnymi lukami, wymuszone aktualizacje Javy i wiedza o konfiguracji skupiona w niewielkiej części zespołu. GitHub Actions ma cenę jawną i przewidywalną, dopóki nie budujecie aplikacji na sprzęt Apple, gdzie minuta kosztuje ponad dziesięć razy więcej niż na Linuksie. Prawdziwy rachunek za migrację nie jest jednak w minutach, tylko na liście, którą publikuje sam GitHub: potoki pisane skryptem, sekrety i wtyczki bez odpowiednika trzeba przenieść ręcznie. Zanim ogłosicie migrację, przenieście jeden potok o średnim znaczeniu od początku do końca. Dopiero ten jeden przypadek powie wam, ile kosztuje cała reszta.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
