buildery?

[Tomasz Kłoczko]

On Mon, 16 Jul 2001, Piotr Meyer wrote:
[..]
> Moje pytanie wzięło się z takiej małej idei. A idea nazywa się
> 'builder at home' :-). Tego typu maszyna kojarzy mi się z czymś,
> co chodzi ciągle, jest cały czas dostępne i duuuże.

Po zainstalowaniu pakiety pld-builder masz szkielet śródowiska które
po uzupełnieniu w chroot o potrzebne tam pakeity daje Ci pełnowartościowe
i tranzakcyjne środowisko do przebudowywania pakietów dokładnie tam gdzie
chcesz :)

Pozostaje Ci wygenrować sobie kluczyk gpg, wstawić go do kółka kluczy na
koncie builder i za pomocą zmodyfikowanego skryptu buildrpm_request z
SPECS możesz zacząć posyłać zlecenia. Jest to o tyle wygodne że zlecenia
mozeszposyłać do bulu i w tym chrootowym środowisku wszystko zostanie
skolejkowane, po zbudowaniu posprządtane i wysłane za pomocą scp w miejsce
gdzie wskażęsz (w konfiguracji skryptów pld-buildera).

W tej chwili w zasadzie brakowałoby tylko listy pakietów które trzeba mieć
zainstalować w chtroot ale to po ostaecznym uporzadkowaniu i odchudzeniu
builderów (mozilla na 386 i 586 już się nie chce pzrebudować na builderach
bo brakuje miejsca) postaram się uzupełnić i wymyśleć jakiś mechanizm żeby
lisę instalwoanych tam pakietów trzymać up to date.

> Tymczasem istnieje na pewno jakiś zbiór developerów, który dysponuje
> maszynami mogącymi przez pewną część dnia służyć do budowania pakietów
> a do tego podpiętymi łączami, które pozwalają w miarę bezboleśnie
> zasysać odpwiednie źródła.

To jest właśnie to co chciałbym niejako wykorzystać do tego żeby
umożliwić WKółkoMacieju kompilowanie pakietów które mamy w celach choćby
testowych.

> Wykorzystanie takich 'częściowo dostępnych' maszyn wymagało by
> jakiegoś mechanizmu pozwalającego synchronizować ich poczyniania.
> Czegoś w rodzaju 'tablicy ogłoszeń' - przychodzi zlecenie
> przebudowania pakietu i jest odnotowywane.

To mozan bardzo łatwo rozwiazać poprzez zmianę aliasów
builder-<arch>@pld.org.pl na listy dyskusyjne. Wtedy kazdy chętny mógłby
zapisać tam własnego buildera po yo żeby na bieżąaco przechwytywać
zlecenia wysyłane przez osoby uprawnione (zlecenie jest podpisywane
kluczek GPG) do tego żeby choćby testowo także i u siebie to
przebudowywać. Tzrebaby tylk ozmienić nieco skrypty pld-buldera żeby
niewysyłał w takich wypadkach adresu zwrotnego wysyłajacego zlecenia do
tego żeby mu podsyłał raporty.
Jesst jeszcze coś co mi się przypomniało, a o czym wie tylko kilka
osób. Otóż jest lista dyskusyjna na którą wysyłają wszystkie obecne
buildery raporty. Jest to podpiete pod pld-logs-builder w pld.org.pl i
wysyłajać pusty list na pld-logs-builder-subscribe w pld.org.pl powino dać
sie tam zapisać. Niemniej ostzregam, że niektóre listy mają i po kilka MB
bo w przypadku kiedy cos jest nie tak to w zwrocie odsyłany jest cały
buildlog.

> Następnie kolejne buildery sprawdzają co jest do zrobienia i w
> zależności od konfiguracji rozpoczynają przebudowę pakietu. W miarę
> sukcesów czy porażek wstawiają odpowiednie informacje do 'tablicy'
> (np. kompilacja zakończona, kompilacja nieudana - błąd taki a taki,
> etc.).

Tu jest zadanie dla beholdera :)
Otóż Maciek kiedyś tworzył bazę SQLową równolegle z specami przechowującą
opisy pakietów. IMHO możnaby w tej bazie trzymać wyniki budowania, a
wrazie jakis kłopotów czy to cały buildlog czy też wskazanie na ftp gdzie
takowy leży.

Tak wogóle to powinniśmy mieć bazę w której zsze są dostępne całe
buildlogi i to niezaleznie od tego czy pakeit przebudował sie prawidłowo
czy nie. Czasami tzreba cos sprawdzić jak się coś kompilowało i czy
napieno było tamwszystko poprawnie. W takich wypadkach szybciej będzie
zajrzeć do leżącego gdzieś buildloga niz bawić sie w ściaganie źródeł z
repo i ich budowanie. To wymagać bezie sporych pojemniości dysku i dlatego
pzrez najbliższe tygodnie jest neirealne .. najbliżesze bo sam czekam na
2x36BG jakie mam dostać niedługo do sparca z E250 z Linuxem, a i po
skończeniu rearganizacji serwera wydziałowego gzie mam prawie 270GB dysków
zostanie mi sporo wolnego miejsca z którego bendę chciał przełożyć także w
kilku dyskach do tej E250tki. Ale to tak czy inaczje nie stanie sie
szybko. Nie szybciej niż w przeciagu miesiaca.

Tak czy imnaczje do rozwoju beholdera trzebaby conajmniej kilku speców od
baz. Sama zawartość takiej bazy miałaby kolosalne znaczenie w wielu
rózncyh miejscach od dalszej automatzacji wykrywanai nowych wersji źródeł
po dostarczanie top listy tych zasobów które osoby majace uprawnienia do
wysyłąnia zleceń na buildery powinny przejrzeć i zatwierdzić neijako do
przebudowania. Zastosowań zresztą takiego zbioru danych może być znacznie
więcej. Każde z takich zastosowań potencjalnie wpływałoby zapewne na
poprawę jakości zasobów i co tu duzó mówić duże oszczędnosci czasu,
którego jak wiadomo nie mamy w niegraniczonych ilościach.

> Następnie taki pakiet mógłby być wrzucany na odpowiedni ftp lub
> przechowywany przez jakiś okres na builderze (tak aby w miarę
> wprowadzania pakietów 'do ludzi' można byłoby go pobrać).

Raczje nie. Buildery jakie są obecnie nie są mocno obciążone. To nie jest
w tej chwili wąskie gardło. Opakietowanie i udokumetowanie lepsze
środowiska do tranzakcyjnego przebudowywania pakietów może mieć wiele
innych zastosowań w tym conajmniej część mogłby być związana z
testowaniem pakietów i bieżącymi pracami nad nimi u każdego z nas.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*