Jest to wpis z serii CICD w embedded i za pierwszym razem zalecane jest przejrzenie wszystkich części po kolei.

  • wpis 1 - budowanie HelloWorld w C na GitLabie
  • wpis 2 - Dodatkowe informacje na temat skryptów budujących
  • wpis 3 - Własny PC/Raspberry jako runner
  • wpis 4 - CubeIDE - przygotowanie testowego projektu
  • wpis 5 - CubeIDE - przygotowanie obrazu dockera do budowania
  • wpis 6 - CubeIDE - budowanie projektu
  • wpis 7 - rozbudowanie skryptów budujących
  • wpis 8 - automatyczne testy jednostkowe
  • wpis 9 - raport pokrycia kodu testami

Uruchomienie budowania aplikacji z gitlaba na prywatnym serwerze

W poprzednim wpisie uzyskaliśmy możliwość budowania obrazu naszej “aplikacji” na serwerach GitLaba. To jednak ma swoje ograniczenia - w darmowej wersji mamy do dyspozycji 400minut pracy tych serwerów na miesiąc (dla prywatnych projetków, publiczne mają go więcej). W opcji premium, gdzie użytkownik to 29$ za miesiąc do dyspozycji jest 10000minut.

Jeśli to nam pasuje - możemy zostać na korzystaniu z oferowanych serwerów przez GitLaba, ale istnieje także opcja rejestracji swoich serwerów i wykorzystania ich do budowania - takie urządzenie będziemy nazywać dalej “GitLab Runnerem”. Tym urządzeniem tak naprawdę może być wszystko - nasz PC, Raspberry Pi czy nawet kontener dockera uruchomiony na czymkolwiek (w tej sytuacji docker uruchamia kolejnego dockera - super sprawa).

Bardzo ważna kwestia pod embedded do czego możemy wykorzystać uruchamianie pipelinów na własnych serwerach - testy sprzętu! Wykorzystując np. Raspberry Pi można łatwo zbudowaną wcześniej aplikację wgrać na nasze urządzenie jako kolejny etap procesu CICD i choćby sprawdzić czy urządzenie uruchomiło się poprawnie. Nie ma nic gorszego niż niedziałający main.

Cel na ten wpis - uruchomić budowanie aplikacji z poprzedniego wpisu na RaspberryPi w moim pokoju - co prawda mam już dość starą wersję - B3, ale w zupełności to wystarczy.

Cała procedura w skrócie:

  • przygotowanie RPi
    • instalacja dockera
    • instalacja GitLab Runnera
  • rejestracja Runnera w GitLabie - wygenerowanie tokenu
  • uruchomienie Runnera podając mu otrzymany wcześniej token
  • wywołanie budowania aplikacji - już na RPi

W sumie nie będę odkrywał tu koła na nowo tylko posłużę się gotową instrukcją + dodam moje komentarze itp.

Link do repozytorium na którym będę to budował -> cicd_simple_test.

  1. Przygotowanie RPi:
  • wgranie czystego systemu - dowolna metoda, ja używam Raspberry Pi Imager
  • generalnie lecimy instrukcją z tej stronki - dev.to
  • ten zestaw komend z poprzedniej stronki polecam wrzucić w skrypt i uruchomić za jednym razem (np. install.sh i zrobić chmod +x install.sh)
# Downloads script and start installation
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
# Adds current user to docker group
sudo groupadd docker # Most likely returns an error, that group already exists
sudo usermod -aG docker ${USER}
groups ${USER} # List all groups, current user belongs to
  • ten skrypt zajmuje jakieś ~20min na RPi3B, pamiętajmy też o restarcie urządzenia
  • jeśli nie chcemy już korzystać z runnerów oferowanych przez GitLab odznaczamy checkbox “Enable shared runners for this group”
  • w nowszej wersji gitlab-runnera możemy podać hosta i token w komendzie rejestrującej - jest to łatwiejsze i sam GitLab to podpowiada przy generowaniu tokena
  • ważna kwestia - runnery mogą być “tagowane” - w ten sposób możemy zarządzać na jakich runnerach co chcemy uruchomić
    • przykład wykorzystania to np. mocniejsze maszyny na pipeline do mergowania, żeby był szybszy feedback z wyniku
    • czy też osobne maszyny, które i budują obraz i też są podłączone do hardware i tylko one zrobią testy HIL itp
    • mój projekt nie miał żadnego taga - dlatego też w ustawieniach runnera trzeba zezwolić mu na uruchamianie rzeczy, które nie mają taga
  • wystartowanie runnera w podstawowej wersji to komenda:
gitlab-runner run
  • możemy teraz przebudować ponownie projekt - tym razem GitLab połączy się z naszym runnerem i to na nim będzie budował
  • pierwsze uruchomienie zawsze potrwa długo - na RPi będzie pierwszy raz tworzony obraz kontenera, następne uruchomienia już będą go reużywać
    • pierwszy build trwał 28m15sek
    • drugi build trwał 2m32sek
  • update - uruchomilem to tez na RPi 5 według tej samej instrukcji i poszło bez problemu - różnica jest w czasach:
    • pierwszy build trwał 1m58sek
    • drugi build trwał 9sek!
    • widać sporą różnicę na plus :) jest to spowodowane wieloma czynnikami - i nowy HW, szybsza karta pamięci, nowsze wersje aplikacji, ale sam się nie spodziwałem aż takiej różnicy

Podsumowanie - zamiast korzystać z Runnerów oferowanych przez GitLaba mogę uruchamiać build na własnym sprzęcie. Praktycznie identyczne flow będzie w przypadku kiedy sami hostujemy serwer GitLaba - jeżeli nasze firma nie chce/nie może trzymać kodu na zewnętrzych serwerach - jedyną różnicą będzie inny adres hosta dla runnera.