Buildery

[Witold Filipczyk]

On Mon, Jan 13, 2003 at 07:45:39PM +0100, "[PLD] Marcin Doliński" wrote:
> Użytkownik Witold Filipczyk napisał:
> >On Mon, Jan 13, 2003 at 05:21:38PM +0100, "[PLD] Marcin Doliński" wrote:
> >
> [...]
> 
> >Schemat i tak będzie uproszczony.
> >Każdy spośród "trusted" users będzie miał dostęp po NFSie do katalogów z 
> >plikami.
> >NFS może być "over ssh".
> >
> >Nie ma potrzeby komplikować tego bardziej.
> >
> >Godziny pracy - po prostu builder jest gotowy, to bierze zlecenie i buduje.
> >Priorytety - nie ma sensu tego implementować, bo kolejki będą krótkie.
> >             Będzie dużo builderów, zawsze można przsunąć jakiś pakiet na 
> >             początek
> >             kolejki.
> >
> OK, mogę się z tym zgodzić. Ale czemu ma być to nfs? W sieci 
> rozproszonej NFS może nie być odpowiednim rozwiązaniem. Ale jeśli chodzi 
> o LAN, to nie powinno być żadnych problemów.
> 
> Kolejna kwestia, na jakiej zasadzie chcesz zrobić tą stację stacją 
> bezdyskową? nfsroot? Ładowanie jakiegoś image np. po nfsie i 
> rozpakowywanie go na ramdysk? Czy za każdym razem chcesz instalować od 
> nowa wszystkie potrzebne devele? Jak często i na czym chcesz generować 
> dla takiego buildera image systemu? Może chcesz go za każdym razem 
> stawiać od nowa? Daj trochę konkretów bo jak na razie Ty też tylko piszesz.

Stacja bezdyskowa - chodziło o nowe komputery, dedykowane do budowania.
Nie warto kupować dysku, lepiej zainwestować w RAM.
Po zbootowaniu system będzie chodził nonstop.  Bezdyskowość nie jest tu istotna.

Wszystkie devele i inne pakiety potrzebne do zbudowania powinny być brane
oczywiście z tego samego źródła.
Napisałem skrypt poldekbuild, który instaluje potrzebne pakiety i uruchamia
rpmbuilda.
Instalacja wszystkiego od nowa, zapewni to, że pakiety będą budowane zawsze
w tym samym środowisku.  Nie będzie sytuacji, że zwykły user nie da rady
przebudować pakietu, bo czegoś nie miał zainstalowanego a na builderach
było.
Dlatego ramdysk tutaj przyspieszyłby trochę. 

> Apropos strony głównej, to jakbyś słuchał kłoczka to też wiedziałbyś, że 
> nie ma możliwości umieszczenia tam linków.

Nie pamiętam co kloczek mówił.  Możliwości są, kwestia koncepcji.

> Piszesz, że każdy będzie mógł zainstalować pakiet i potrenować budowanie 
> a wcześniej napisałeś, że ma się to odbywać automatycznie.

Będą pakiety z builderem.  Każdy będzie mógł zainstalować te pakiety
i sprawdzić jak to działa.  A jak spełni odpowiednie warunki,
(jakie - nie wiem), będzie mógł użyć swojej maszyny do budowania
oficjalnych zasobów.

> Mój pomysł jest taki: buildery oczywiście w chroocie. Nie wiem jak to 
> zabezpieczyć przed ingerencją nieświadomych 'adminów' ale trzeba 
> poszukać jakiejś metody... Builder dla lusera powinien działać tak jak 

Oczywiście builder będzie działał w chroocie.  Ma instalować pakiety od zera.

> Seti w Home - user nie wie co i dla kogo robi ani nie ma za dużych 
> możliwości ingerencji w to. Powinna być w sieci lista pakietów, których 

Mam zamiar zrealizowania "Multi w Home" - wyszukiwanie zależności w losowaniach
Multilotka, ale to inna bajka.

> pilnowałby się builder. Np. co godzine powinien sprawdzać czy ma 
> wszystkie pakiety z listy w odpowiednich wersjach i np. sprawdzać 
> różnicę ls -lR z wzorcem. Jeżeli jest inaczej, nie dochodzi do 

Nie wiesz jak to zrobić, nie wiesz nawet dokładnie jak to ma działać.

Skrypt poldekbuild (wysłałem go na listę poldkową w tamtym roku)
instaluje wszystkie potrzebne pakiety i tylko te pakiety.

> Napisz jeszcze dokładnie jak miałby działać taki builder (jego system).

Chyba już pisałem, ale napiszę jeszcze raz.

developer robi commita.  Jeśli w specu zmienił się Release lub Version lub
jeszcze coś innego, np. w pakietach z Release poniżej 1, mamy request
dla buildera.
Albo od razu jest budowany pakiet src.rpm, albo request przekazywany
jest dalej. (zależy od implementacji, nie jest istotne w tej chwili)

Tzn. wszystko opiera się o kolejki.  Kolejki to nic innego jak katalogi,
w których są pliki.  O kolejności decyduje czas modyfikacji, np.

Kolejka zleceń zrobienia src.rpma będzie zawierała pliki .spec.
Zawartość nie musi być kopiowana wystarczy nazwa, zawartość można
wziąć z cvsu.

Będzie też kolejka SRPMS do przebudowania i RPMów do podpisania.
Na każdej kolejce będzie operował w nieskończonej pętli jakiś skrypt.
Będzie brał pierwszy (najstarszy) element z kolejki, przetwarzał
go i zapisywał wyniki w innych kolejkach (katalogach).
Jeśli kolejka jest pusta proces zasypia na określony czas.

Pierwszy element z kolejki to:
ls -t | head -1

Przepływ danych wygląda tak:
.spec -> .src.rpm -> .rpm  -> .log , oprócz tego pliki są kopiowane
w odpowiednie miejsca i rpmy podpisywane.

Załóżmy, że mamy katalog z src.rpm.
Dla każdej architektury jest podakatalog, w którym są linki symboliczne
do plików z katalogu SRPMS, np.

i686/blabla.src.rpm -> /SRPMS/blabla.src.rpm

i386/blabla.src.rpm -> /SRPMS/blabla.src.rpm


A więc teraz dla każdej architektury mamy buildery.  Każdy z builderów
ma dostęp po NFSie do src.rpm.  Na każdym builderze działa program
budujący.
Bierze pierwszy pakiet z kolejki.  W tym czasie dostęp do katalogu
jest blokowany, żeby dwa buildery nie wzięły do przebudowania
tego samego pakietu.  Przerzuca pakiet do katalogu BUDOWANE.

mv blabla.src.rpm BUDOWANE/

linki były bezwzględne, więc wszystko jest w porządku.

Odpalany jest właściwy skrypt buildera.
W chrootowanym środowisku instalowane są potrzebne pakiety.
Pakiet jest budowany.  Wynik budowania (OK albo FAIL),
a także log z budowania jest kopiowany w odpowiednie miejsce.
Kasowany jest plik (link) BUDOWANE/blabla.src.rpm

Builder może budować następny pakiet.

NFS zapewnia prostotę. Przy połączeniach 1Mbit/s i szybszych nie powinno
być dużych opóźnień.

Jeśli w wyniku powstaną RPMy zostaną skopiowane do kolejki podpisywacza.
Na tej samej zasadzie podisywacz bierze pierwszy pakiet z kolejki,
podpisuje go i wrzuca do test.  Co się dzieje dalej to już nie nasza
sprawa.

Jeśli zostanie osiągnięta "masa krytyczna" builderów, to developerzy nie
nadążą z produkcją speców.

-- 
Witold Filipczyk
<witekfl w poczta.onet.pl>