Tag: continuous integration

5 powodów, czemu GitLab CI w 2026 jest cieniem GitHub Actions

GitLab CI odstaje od GitHub Actions w ważnych obszarach: w integracji z narzędziami AI, automatyzacji pracy z komentarzami, bezpieczeństwie kluczy API.

Jak CI to GitLab? Taka była prawda 10 lat temu. Może nawet była to prawda 5 lat temu. Ale na tym koniec. Czas zaktualizować wiedzę.

Miałem bardzo duży sentyment do GitLaba, odkąd uwolnił mnie od konieczności zadawania się z Jenkinsem czy jeszcze gorszymi potworkami. Jeśli, podobnie jak do niedawna ja, myślisz pozytywnie o GitLabie, ten artykuł jest dla ciebie. Pokażę, czemu w 2026 roku nie ma sensu opierać komercyjnego lub opensource’owego Continuous Integration o tę platformę.

Nie będę pisał, który YAML jest bardziej estetyczny albo łatwiejszy do czytania. W dalszej części podam 5 obiektywnych obszarów, gdzie GitHub Actions daje konkretne przewagi: przy integracji z narzędziami AI, nie-AI-owej automatyzacji pull/merge requestów, bezpieczeństwie kluczy API, albo po prostu na minutach pracy chmury obliczeniowej kompilującej nasz kod.

To krótki artykuł. O porównaniu wszystkich możliwości platform CI można by pisać książki. Ja zwracam uwagę tylko na wycinek, ale moim zdaniem bardzo znaczący.

Czytaj dalej

editorconfig na CI – automatyczna weryfikacja jednolitego stylu

Większość języków programowania ma swój style checker tudzież linter. Czy to wystarcza? Jeśli do tej pory w repozytorium miałeś/aś tylko CheckStyle, to mam zamiar przekonać Cię, że warto dorzucić też plik .editorconfig. Napiszę też, czemu należy standard editorconfig wspierać na serwerze CI i jak to zrobić – moją propozycją jest narzędzie editorconfig-checker. Jego największą zaletą jest niezależność od typu naszego projektu. Czy to rozbudowana aplikacja w Javie albo TypeScripcie, czy repozytorium zbierające luźno powiązane skrypty w Pythonie i Bashu – zawsze będzie przydatne.

Mnie do wpięcia tego narzędzia do continuous integration przekonała typowa sytuacja – w pewnym repozytorium edytowałem dwa skrypty shellowe, w jednym ktoś narobił wcięcia spacjami, w drugim ktoś inny tabulacjami. Nie widać różnicy na pierwszy rzut oka, wstawiłem linijkę tu, linijkę tam. Patrzę w git diff, a tam moje linijki nie równają się z otoczeniem, do tego w zmianach pojawiło się \ No newline at end of file, czyli ktoś nie używał poprawnie ustawionego edytora tekstu. Potem znalazłem Dockerfile wcinany raz to spacjami, a raz to tabulacjami.

Czytaj dalej