Aktywne Wpisy

JPRW +477
Naród polski ginie, bo dzieci nie jedzą wafli w kościele. Mam nadzieję, że Konfunia w ramach wolnościowej polityki wprowadzi jakiś przymus uczestnictwa w obrzędach religijnych.
#bekazkonfederacji #bekazprawakow #bekazkatoli #heheszki
#bekazkonfederacji #bekazprawakow #bekazkatoli #heheszki
źródło: 20240512_172830
Pobierz
moll +96
Tunel już stoi! Trochę pomagałam, ale na tyle dobra konstrukcja, że mój niebieski postawiłby praktycznie sam (z trochę większymi trudnościami)
@_aqq wołam, bo chcialeś zobaczyć na gotowo
#ogrodnictwo
@_aqq wołam, bo chcialeś zobaczyć na gotowo
#ogrodnictwo
źródło: signal-2024-05-12-18-26-27-091-2
Pobierz




Załóżmy, że mam repo R1, w którym mam warstę BSP dla różnych maszyn, drivery, oraz warstwę dla mojego distro. W repo R2, mam meta-warstwę opisującą konkretny projek (P1) który wykorzystuje m.in. warstwy z R1. Mam też repo R3, które zawiera kod jednej z aplikacji, która jest budowana (za pomocą SDK dla P1), paczkowana (Conan dla C++), a następnie wrzucana na nexusa.
Podczas budowania obrazu dla P1, powinny zostać pobrane warswy z R1, oraz paczka z nexusa zbudowana na podstawie R3. I to jest okej, generalnie powinno działać. Pytania są natomiast następujące:
- robię commit do R1, w którym zmieniam np. kod drivera, który jest istotny dla P1, jak z perspektywy CI mógłbym skonfigurować tak aby obraz P1 automatycznie się przebudował?
- robię commit do R3, aplikacja się buduje, paczkuje i leci na nexusa, jak z perspektywy CI striggerować build dla P1?
Jak widać zaróno kod R1, oraz R3 które są istotne dla P1, są w innych repo, więc tak naprawdę z perspektywy R2 nic się nie zmieniło, żaden commit nie doszedł więc jakikolwiek CI dla tego repo się nie striggeruje.
Mówiąc o CI mam na myśli jakiekolwiek narzędzia, których używacie w pracy aby to osiągnać. Chce sobie coś takiego zbudować dla prywatnych projektów, bo trochę mi sie to rozrasta i chciałbym dodać właśnie jakaś automatyzację, natomiast jeżeli chodzi o CI/CD to jestem dość zielony, bo to totalnie nie moja działka. W firmowych projektach tak to działa, że jakiekolwiek zmiany pojawią się w repozytoriach, które składają się na finalny produkt, automatycznie triggerują się build, oraz build ostatecznego produktu, tzw. UpgradePackage, który zawiera komplet softu potrzebnego do zaktualizowania sprzętu. Staram się przeanalizować jaki mechanizm jest u nas i jak to działa, ale jest to dość skomplikowane, bo projekty są wieloletnie i na ogromną skalę.
#programowanie #embedded #devops