-1. Developer wysy³a zlecenie, z u¿yciem client/make-request.sh, na adres
+1. Developer wysyła zlecenie, z użyciem client/make-request.sh, na adres
srpm buildera.
-2. Na koncie srpm buildera skrypt request_handler.py wo³any z procmaila obs³uguje
+2. Na koncie srpm buildera skrypt request_handler.py wołany z procmaila obsługuje
zlecenie.
- a) sprawdza podpis gpg, wyci±ga wszystkie Good sinature from <...>
- je¶li brak -- wypad
- b) szuka w swoim acl.conf czy osoba z Good signature from mo¿e robiæ
+ a) sprawdza podpis gpg, wyciąga wszystkie Good sinature from <...>
+ jeśli brak -- wypad
+ b) szuka w swoim acl.conf czy osoba z Good signature from może robić
cokolwiek, w.p.p wypad
c) xml-parsuje zlecenie (request.py)
- i. je¶li jest to <notifcation ...>, sparawdza uprawnienie
- notify:<builder>, i je¶li OK, to zmienia odpowiednio
- kolejkê spool/req_queue. Je¶li wszystki buildery
- zakoñczy³y ju¿ budowanie danej grupy usuwane s± src rpmy
- z www/srpms/<group-id>/. Generuje stronê ze statystykami
+ i. jeśli jest to <notifcation ...>, sparawdza uprawnienie
+ notify:<builder>, i jeśli OK, to zmienia odpowiednio
+ kolejkę spool/req_queue. Jeśli wszystki buildery
+ zakończyły już budowanie danej grupy usuwane są src rpmy
+ z www/srpms/<group-id>/. Generuje stronę ze statystykami
(www/queue.html).
- ii. je¶li jest to <group ...> to sprawdza czy u¿ytkownik,
- który wys³a³ zlecenie ma uprawnienia src:<nazwa-src-buildera>,
- oraz binary:<builder> dla ka¿dego buildera dla którego jest
- zlecenie. Je¶li OK, to wrzuca zlecenie do spool/queue
+ ii. jeśli jest to <group ...> to sprawdza czy użytkownik,
+ który wysłał zlecenie ma uprawnienia src:<nazwa-src-buildera>,
+ oraz binary:<builder> dla każdego buildera dla którego jest
+ zlecenie. Jeśli OK, to wrzuca zlecenie do spool/queue
3. Na koncie srpm buildera z crona chodzi skrypt srpm_builder.py.
- a) Czyta spool/queue, je¶li s± tam jakie¶ zlecenia, sortuje wg. priorytetu
- (ni¿szy numer == wa¿niejsze zlecenie), a nastêpnie sortuje wg. czasu
- przybycia zlecenia (starsze == wa¿niejsze), wyci±ga je z kolejki i zapisuje
- kolejkê.
- b) Obs³uguje tylko <group ...>.
- c) Buduje w chroot wszystkie pakiety z grupy, kolejkuj±c pliki w spool/ftp/
- oraz spool/buildlogs/. Dodatkowo srpmy s± wrzucane do www/srpms/<group-id>/
- sk±d ci±gn± je bin-buildery.
- d) je¶li nie powiod³o siê budowanie ¿adnego pakietu to wypad
+ a) Czyta spool/queue, jeśli są tam jakieś zlecenia, sortuje wg. priorytetu
+ (niższy numer == ważniejsze zlecenie), a następnie sortuje wg. czasu
+ przybycia zlecenia (starsze == ważniejsze), wyciąga je z kolejki i zapisuje
+ kolejkę.
+ b) Obsługuje tylko <group ...>.
+ c) Buduje w chroot wszystkie pakiety z grupy, kolejkując pliki w spool/ftp/
+ oraz spool/buildlogs/. Dodatkowo srpmy są wrzucane do www/srpms/<group-id>/
+ skąd ciągną je bin-buildery.
+ d) jeśli nie powiodło się budowanie żadnego pakietu to wypad
e) zleceniu nadawany jest numer
f) zlecenie jest wrzucane do spool/req_queue
g) kolejka jest podpisywana kluczem srpm buildera, gzipowana i wrzucana do
h) numer zapisywany jest w www/max_req_no
i) generowanie strony ze statystykami
-4. Na kontach srpm buildera i bin-builderów chodzi
- file_sender.py. Monitoruje on kolejki spool/{buildlogs,ftp}. S± w
+4. Na kontach srpm buildera i bin-builderów chodzi
+ file_sender.py. Monitoruje on kolejki spool/{buildlogs,ftp}. Są w
nich pliki, jak:
faa1f592-437f-446d-b1e6-ac41976c5775
faa1f592-437f-446d-b1e6-ac41976c5775.info
faa1f592-437f-446d-b1e6-ac41976c5775.desc
- Plik .desc jest kontrolny dla file_sender.py. Zawiera email zlecaj±cego
- (do alarmowania), czas skolejkowania (pliki s± wysy³ane dok³adnie
- w kolejno¶ci wrzucania do kolejki), oraz cel (url), gdzie nale¿y
- przes³aæ plik.
+ Plik .desc jest kontrolny dla file_sender.py. Zawiera email zlecającego
+ (do alarmowania), czas skolejkowania (pliki są wysyłane dokładnie
+ w kolejności wrzucania do kolejki), oraz cel (url), gdzie należy
+ przesłać plik.
- Plik .info jest tylko dla buildlogów. Je¶li taki plik istnieje to jest
- przesy³any po przes³aniu w³a¶ciwego pliku (tego bez rozszerzenia). Jest
+ Plik .info jest tylko dla buildlogów. Jeśli taki plik istnieje to jest
+ przesyłany po przesłaniu właściwego pliku (tego bez rozszerzenia). Jest
w nim zapisany status buildloga (OK|FAIL). helpers/buildlogs-mover.sh
- u¿ywa tych plików.
+ używa tych plików.
- Pliki .info i .desc koñcza siê lini±, zawieraj±c± s³owo END. Skrypty
- nic z nimi nie robi± je¶li nie ma tam tego s³owa (transmisja
- niedokoñczona).
+ Pliki .info i .desc kończa się linią, zawierającą słowo END. Skrypty
+ nic z nimi nie robią jeśli nie ma tam tego słowa (transmisja
+ niedokończona).
URLe wspierane jako cel to:
scp://user@host/sciezka/plik
/absolutna/sciezka/do/pliku
- W pliki config/rsync-passwords s± has³a do rsync, w formacie:
+ W pliki config/rsync-passwords są hasła do rsync, w formacie:
- user@host has³o
+ user@host hasło
- scp dzia³a po kluczach (z ~/.ssh)
+ scp działa po kluczach (z ~/.ssh)
5. Na koncie bin-buildera chodzi skrypt request_fetcher.py.
- a) ¶ci±ga $control_url/max_req_no i porównuje ze spool/last_req_no.
- je¶li takie same to wypad.
- b) ¶ci±ga $control_url/queue.gz, dekompresuje, sprawdza podpis (w
- config/acl.conf dla podpisuj±cego u¿ytkownika musi byæ
+ a) ściąga $control_url/max_req_no i porównuje ze spool/last_req_no.
+ jeśli takie same to wypad.
+ b) ściąga $control_url/queue.gz, dekompresuje, sprawdza podpis (w
+ config/acl.conf dla podpisującego użytkownika musi być
"sign_queue:all") [sidenote: konto bin buildera nie potrzebuje
- kluczy gpg innych ni¿ swój i srpm buildera, nie potrzebuje te¿
- acl.conf pe³nego, tylko srpm_builder z sign_queue:all]
+ kluczy gpg innych niż swój i srpm buildera, nie potrzebuje też
+ acl.conf pełnego, tylko srpm_builder z sign_queue:all]
c) wrzuca zlecenia do spool/queue
- d) zapisuje najwiêkszy numer zlecenia wrzuconego w spool/last_req_no.
+ d) zapisuje największy numer zlecenia wrzuconego w spool/last_req_no.
6. Na koncie bin-buildera chodzi skrypt rpm_builder.py.
- a) sprawdzenie loadu, je¶li za wysoki to papa
- b) lockowanie build-slot-N, gdzie N < job_slots, je¶li sie nie da
+ a) sprawdzenie loadu, jeśli za wysoki to papa
+ b) lockowanie build-slot-N, gdzie N < job_slots, jeśli sie nie da
to papa
c) lockowanie building-rpm-for-<builder> (tylko jeden build w chroot
na raz)
- d) Czyta spool/queue, je¶li s± tam jakie¶ zlecenia, sortuje wg. priorytetu
- (ni¿szy numer == wa¿niejsze zlecenie), a nastêpnie sortuje wg. czasu
- przybycia zlecenia (starsze == wa¿niejsze), wyci±ga je z kolejki i zapisuje
- kolejkê.
- e) buduje pakiety, wrzuca pliki do spool/{buildlogs,ftp}. Je¶li nie ma flagi
- test-build to pakiety wrzuca te¿ do /spools/ready/ w chroot (i generuje
+ d) Czyta spool/queue, jeśli są tam jakieś zlecenia, sortuje wg. priorytetu
+ (niższy numer == ważniejsze zlecenie), a następnie sortuje wg. czasu
+ przybycia zlecenia (starsze == ważniejsze), wyciąga je z kolejki i zapisuje
+ kolejkę.
+ e) buduje pakiety, wrzuca pliki do spool/{buildlogs,ftp}. Jeśli nie ma flagi
+ test-build to pakiety wrzuca też do /spools/ready/ w chroot (i generuje
tam idx poldka)
-Budowanie pakietów:
- 1. ¶ci±gniêcie srpm
+Budowanie pakietów:
+ 1. ściągnięcie srpm
2. instalacja srpm
- 3. próba budowania (z --nobuild), wy³apanie "foo is needed by ...",
- instalacja wszystkich takich foo. UWAGA: to nie zawsze dzia³a, np. je¶li
- rpm wywali siê z braku pliku do %include. trzeba napisaæ osobny parser.
+ 3. próba budowania (z --nobuild), wyłapanie "foo is needed by ...",
+ instalacja wszystkich takich foo. UWAGA: to nie zawsze działa, np. jeśli
+ rpm wywali się z braku pliku do %include. trzeba napisać osobny parser.
4. budowanie
- 5. je¶li nie test-build to przerzucenie pakietów do /spools/ready/
- 6. je¶li upgrade, to próba upgrejdu, wywalenie wszystkich przeszkadzaj±cych
- pakietów, chyba, ¿e trzeba by wywaliæ poldka, lub rpm-build.
+ 5. jeśli nie test-build to przerzucenie pakietów do /spools/ready/
+ 6. jeśli upgrade, to próba upgrejdu, wywalenie wszystkich przeszkadzających
+ pakietów, chyba, że trzeba by wywalić poldka, lub rpm-build.
7. upgrade