Skip to content
GitLabGitHub

gitlab-ci

6 posts with the tag “gitlab-ci”

Renovate - Automatyczne wykrywanie aktualizacji

Utrzymanie aktualnych zależności w repozytoriach to jedno z kluczowych wyzwań w nowoczesnych projektach IT. Ręczne sprawdzanie nowych wersji bibliotek, obrazów kontenerowych czy narzędzi infrastrukturalnych jest czasochłonne i podatne na błędy, a jednocześnie ma bezpośredni wpływ na bezpieczeństwo i stabilność systemów.

W tym wpisie pokażę, jak wykorzystuję Renovate do automatycznego wykrywania aktualizacji oraz integracji tego procesu z GitLab CI. Celem jest pełna automatyzacja — od detekcji nowych wersji zależności, przez tworzenie merge requestów, aż po kontrolę nad tym, kiedy i w jaki sposób aktualizacje trafiają do projektu.

AI Review - Codex w gitlab-ci

Od dawna, pracując nad własnymi projektami w homelabie i traktując je jako przestrzeń do nauki oraz eksperymentów, brakowało mi jednego elementu – kogoś, kto spojrzy na mój kod z dystansu. Nie w kontekście pracy zespołowej, bo tam code review jest naturalnym elementem procesu, ale w prywatnym środowisku, gdzie większość decyzji podejmuje się samodzielnie.

Sztuczna inteligencja zaczęła pełnić rolę cichego recenzenta — analizuje kod, podpowiada możliwe usprawnienia, wyłapuje potencjalne problemy i robi to dokładnie tam, gdzie i tak już wszystko się dzieje: w pipeline CI/CD. W tym artykule pokazuję, jak wykorzystuję AI Review – Codex w gitlab-ci w homelabie jako narzędzie edukacyjne, które realnie wspiera naukę, eksperymentowanie i podnoszenie jakości własnych projektów.

Testowanie konfiguracji za pomocą conftest

Wraz ze wzrostem złożoności procesów automatycznego budowania obrazów systemowych rośnie potrzeba wczesnej walidacji konfiguracji, zanim trafią one do właściwego procesu buildowania. W tym artykule pokażę, jak za pomocą Conftest oraz procesów CI/CD zautomatyzować testowanie plików YAML wykorzystywanych przez image-buildera, eliminując błędy konfiguracyjne jeszcze na etapie pipeline’u.

Skanowanie podatności w kontenerach

Zapewnienie bezpieczeństwa obrazów kontenerowych w procesie CI/CD może wydawać się dodatkowym obciążeniem, jednak w praktyce da się je zautomatyzować w prosty i powtarzalny sposób. W tym wpisie pokażę, jak zintegrować narzędzie Trivy z pipeline’em CI/CD, aby skutecznie wykrywać podatności bezpieczeństwa w budowanych obrazach kontenerowych jeszcze przed ich publikacją.

Trivy realizuje zasadę “shift left security”, czyli:

  • skanowanie jak najwcześniej w cyklu wytwórczym,
  • automatyczne blokowanie artefaktów niespełniających wymagań bezpieczeństwa.

Może analizować m.in.:

  • obrazy kontenerowe (Docker, OCI),
  • filesystem (repozytorium kodu),
  • IaC (Terraform, Kubernetes YAML, Helm),
  • SBOM (Software Bill of Materials).

Image builder

Budowanie własnych kontenerów w procesie CI/CD może wydawać się skomplikowane, ale wcale nie musi takie być. W tym wpisie pokażę krok po kroku, jak przygotować pipeline do budowania i publikowania obrazów kontenerowych z użyciem narzędzia Buildah.

Dziś przedstawie wam, jak zbudowałem własny image builder, krok po kroku.

Buildah pozwala tworzyć obrazy kontenerów bez uruchamiania demona i bez konieczności posiadania Dockera.

  • Brak demona Buildah działa jako zwykłe polecenie CLI – nie wymaga działającego serwisu w tle (jak dockerd).
  • Rootless (bez uprawnień roota) Może budować obrazy jako zwykły użytkownik, co znacząco poprawia bezpieczeństwo.
  • Zgodność z OCI / Docker Tworzone obrazy są w pełni kompatybilne z Dockerem, Podmanem, Kubernetesem itd.
  • Skryptowalność Buildah jest zaprojektowany jako zestaw niskopoziomowych poleceń (buildah from, buildah run, buildah commit), idealnych do automatyzacji w bashu lub CI.
  • Dockerfile – opcjonalnie Obsługuje Dockerfile (buildah bud), ale nie wymusza ich użycia.

Utworzenie procesu CI dla opentofu

W tym artykule opiszę jak zbudowałem własny centralne repozytorium dla opentofu