CRACI vs Jenkins | Zarządzane GitHub Actions a własne CI

Krótka odpowiedź

Jenkins określa się jako wiodący serwer automatyzacji open source i ma ku temu powody: działa wszędzie, gdzie zostanie zainstalowany, rozdziela pracę na tyle maszyn, ile mu Państwo dadzą, a ponad 2300 wtyczek społeczności łączy go niemal z każdym narzędziem. Jeśli buildy muszą pozostać w całości w Państwa własnej sieci albo pipeline'y zależą od wtyczek bez odpowiednika gdzie indziej, Jenkinsa trudno zastąpić.

CRACI to inny rodzaj produktu. To zarządzany runner dla GitHub Actions: nie ma kontrolera do aktualizowania ani agenta do łatania. Podczas działania każdego zadania CRACI rejestruje każdą zewnętrzną zależność pobieraną przez build, egzekwuje politykę ruchu wychodzącego w sieci buildu i na podstawie tego zapisu tworzy SBOM-y, dane o pochodzeniu i monitorowanie podatności. Jenkins może robić część tego przez wtyczki, które Państwo wybierają, konfigurują i aktualizują; CRACI czyni zapisem bezpieczeństwa sam runner.

Najpierw jedna kwestia praktyczna. CRACI obsługuje dziś GitHub Actions, a Jenkins i GitLab CI są w planach rozwoju, bez określonej daty. Aby działać na CRACI już teraz, pipeline Jenkins musi najpierw przejść na workflow GitHub Actions.

W skrócie

Funkcja	CRACI	Jenkins
Czym jest	Zarządzany, bezpieczny runner dla GitHub Actions.	Serwer automatyzacji open source hostowany przez Państwa.
Co Państwo utrzymują	Nic: żadnego kontrolera ani agenta do uruchamiania.	Kontroler, agenty, aktualizacje i wtyczki.
Jak powstaje SBOM	Rejestrowany z tego, co pobrało każde zadanie, ze stanem kompletności	Wtyczki lub narzędzia dodane przez Państwa
Polityka ruchu wychodzącego buildu	Domyślna odmowa lub zezwolenie, walidowana przed zadaniem, blokuje w razie błędu	Do zbudowania przez Państwa, na własnych agentach
Monitorowanie podatności	Monitorowane SBOM-y stale ponownie oceniane	Wtyczki lub narzędzia dodane przez Państwa
Systemy CI	Dziś GitHub Actions; GitLab CI i Jenkins w planach rozwoju	Pipeline'y Jenkins, większość systemów kontroli wersji przez wtyczki
Windows i macOS	Dziś Linux na x86-64 i ARM64	Dowolny uruchomiony przez Państwa agent
Działa na własnych maszynach	Runnery hostowane u klienta, Enterprise	Jedyna opcja
Rozszerzalność	GitHub Actions i ich marketplace akcji.	Ponad 2300 wtyczek społeczności.
Cena	$0.004 za minutę ($0.002 za minutę vCPU), naliczane co sekundę. Bez opłaty miesięcznej i bez opłat za SBOM.	Bezpłatny i open source; płacą Państwo za maszyny i ludzi, którzy je utrzymują.

W zestawie
Częściowo
W planach rozwoju

Co Jenkins robi dobrze

Działa tam, gdzie jest potrzebny. Jenkins działa na Państwa własnych serwerach, w Państwa własnej sieci, bez płaszczyzny sterowania SaaS. Agentami mogą być maszyny z Linuxem, Windows, macOS lub każda inna maszyna, którą można podłączyć, więc jeden kontroler może zbudować backend, klienta desktopowego i firmware.

Wtyczki niemal do wszystkiego. Ekosystem wtyczek to największa siła Jenkinsa. Wtyczki istnieją dla kontroli wersji, narzędzi buildu, raportów testów, celów wdrożeń i skanerów bezpieczeństwa, a zespoły z nietypowymi toolchainami często stwierdzają, że Jenkins to jedyne CI, które już je obsługuje.

Bez kosztów licencji. Jenkins jest bezpłatny i open source. Kosztem są maszyny, na których działa, oraz czas, który Państwa zespół poświęca na jego utrzymanie.

Czym różni się CRACI

Nic do utrzymywania

Instalacja Jenkinsa to system należący do Państwa zespołu: kontroler, agenty, wtyczki i aktualizacje. Projekt Jenkins często publikuje biuletyny bezpieczeństwa dotyczące rdzenia i wtyczek, w 2026 roku kilka miesięcznie (na przykład 2 i 16 września oraz 5 sierpnia), a wdrożenie każdego z nich należy do Państwa. CRACI uruchamia zadania na zarządzanych runnerach, w izolowanych maszynach wirtualnych, po jednej na zadanie, więc nie ma serwera buildów, który trzeba by łatać.

SBOM pochodzi z buildu

W Jenkinsie SBOM pochodzi z dodanej wtyczki lub kroku skanera, które zwykle odczytują manifesty i lockfile po fakcie. Buildy często robią więcej, niż mówią te pliki: skrypty instalacyjne pobierają kod, skrypty buildu pobierają zasoby w czasie buildu, a cache przywracają pakiety, o których nie wspomina żaden lockfile. CRACI widzi ten ruch, ponieważ jest runnerem. Proxy rozpoznające pakiety rejestruje, co każde zadanie pobiera ze źródeł pakietów: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk i źródeł Git, a dowody zależności przemieszczają się razem z cache CI. Każdy SBOM CycloneDX lub SPDX określa swoją kompletność dla każdego zadania i każdego cache.

Polityka dla sieci buildu

W Jenkinsie kontrola nad tym, do czego build może dotrzeć, oznacza reguły zapory lub proxy wokół agentów, które sami Państwo projektują i utrzymują. W CRACI polityka ruchu wychodzącego dla każdego zadania decyduje, do których hostów może ono dotrzeć: domyślna odmowa lub domyślne zezwolenie, z 24 wbudowanymi presetami źródeł oprogramowania i typowanymi źródłami niestandardowymi, walidacja przed startem zadania. Polityki w razie błędu blokują ruch, a naruszenia wysyłają alert.

Monitorowanie tego, co dostarczono

API zwraca SBOM-y, ślady sieciowe i dane o pochodzeniu. CRACI agreguje podatności z wielu buildów i repozytoriów, nadal ponownie ocenia monitorowane SBOM-y w miarę pojawiania się biuletynów i pokazuje, które wcześniejsze buildy zawierały podatną zależność, dzięki czemu wiedzą Państwo, w jakim okresie byli narażeni.

Rozliczenie za minutę buildu

Jenkins nie ma opłaty licencyjnej, ale jego działanie nie jest darmowe: płacą Państwo za kontroler i agenty, bezczynne czy zajęte, oraz za ludzi, którzy je aktualizują. CRACI pobiera opłaty tylko za minuty buildu: $0.002 za minutę vCPU ($0.004 za domyślny runner 2 vCPU), naliczane co sekundę, bez opłaty miesięcznej i bez opłat za SBOM.

Co wybrać

Warto pozostać przy Jenkinsie, jeśli buildy muszą działać w całości na Państwa infrastrukturze, jeśli zależą Państwo od wtyczek bez odpowiednika w GitHub Actions, jeśli potrzebują Państwo buildów Windows lub macOS albo jeśli mają Państwo ludzi do jego utrzymania i wszystko działa.
Warto wybrać CRACI, jeśli Państwa kod jest w GitHub, przenoszą Państwo pipeline'y do GitHub Actions lub są na to gotowi i chcą przestać utrzymywać serwery buildów, zyskując zapis tego, co trafiło do każdego wydania.
Warto używać obu podczas stopniowej migracji: nowe projekty i pipeline'y Linux przenieść do GitHub Actions na CRACI, a stabilne zadania Jenkins pozostawić tam, gdzie są.

Warto jasno określić, z czego rezygnują Państwo, wybierając dziś CRACI. Uruchamia tylko zadania Linux, a Windows i macOS są w planach rozwoju; runnery hostowane u klienta są w planach rozwoju dla Enterprise; a pipeline'y Jenkins muszą stać się workflow GitHub Actions, dopóki nie pojawi się obsługa Jenkinsa.

Dla produktów regulowanych

Frameworki takie jak unijny Cyber Resilience Act oczekują od producentów, że będą wiedzieć, co jest w każdym wydaniu, i obsługiwać jego podatności, z obowiązkami raportowania od września 2026. W Jenkinsie te dowody pochodzą z wtyczek i skanerów, które podłączą Państwo do każdego pipeline'u. CRACI wytwarza je z zapisu buildu i eksportuje SBOM-y w formacie CycloneDX lub SPDX. Automatyzuje znaczną część widoczności łańcucha dostaw oprogramowania i dowodów potrzebnych firmie w szerszym procesie CRA; żadne z tych narzędzi samo nie zapewnia zgodności produktu.

Przeniesienie pipeline'u do CRACI

GitHub Actions Importer od GitHub konwertuje pipeline'y Jenkins na workflow GitHub Actions. GitHub zakłada automatyczną konwersję 80% każdego workflow i podaje, że każdy skonwertowany workflow należy sprawdzić przed uruchomieniem na produkcji, więc warto zaplanować trochę pracy ręcznej. Gdy pipeline działa już jako workflow GitHub Actions, uruchomi się na CRACI po zmianie jednej linii:

runs-on: craci

Uruchomienia nadal są widoczne w interfejsie GitHub. Więcej o generowaniu SBOM w czasie buildu, a także alternatywy dla Jenkinsa, porównanie platform CI/CD i ceny.