problem z cvs-em

[Tomasz Kłoczko]

On Sat, 14 Jul 2001, Jacek Konieczny wrote:

> On Sat, Jul 14, 2001 at 01:26:25PM +0200, bob wrote:
> > sic! właśnie podałeś procedure testową dla pakietu cvs
> > teraz wystarczy , żeby z każdym pakietem była składowana taka procedura 
> > i żeby pakiet musiał ja pomyślnie przejść zanim trafi z test na ftp.

> Na początku nie spodobało mi się to co napisałeś. Jeśli to miałby
> ręcznie robić każdy developer PLD, to ja chyba bym se darował robienie
> pakietów. Ale po chwili zastanowienia.... dochodzę do wniosku, że należy
> zrobić po prostu nowy moduł w CVS: regtest, gdzie będą umieszczane
> skrypty robiące testy regresyjne pakietów. Wszystkiego nie da się tak
> przetestować, ale wiele owszem. 
> Pod taki test musiałoby być przygotowane odpowiednie środowisko (np.
> przez nadrzędny skrypt "tester") znaczy się np. katalog roboczy, na
> którym będzie mógł test pracować.

Oczywistym jest, że byłoby to potrzebne.
Niemniej nie wiem czy robienie jednego narzędzia jest konieczne. Wydaje mi
się, że zespół mnarzędzi wykonujących (każde) elementarny test byłby chyba
różnie dobry co może nawet użyteczniejszy.
Tak czy inaczje to tylko dywagacja bo zapewne to czy bedzie lepsze jedno
narzędzie do wykonywanai serii testów czy stado takowych wyjdzie w prani.

W tej chwili istnieją już przynajmniej dwa elementy takiego testowania oba
w katalogu /stat i są one wykonywane przy każdej regenracji indeksów apta,
wucha i poldka. Pierwszy to sprawdzenie zależności między pakietami (wuch
-D), a drugi to wykonanie porównia listy dosępnych pakietów. Wynik
pierwszego testu wpada w pliki .chk, a drugiego w .diff gdzie platformą
referencyjną jest i386.
To tylko dwa z aspektów takeigo testowania i na pewno nie najważniejsze.

> Dla cvs taki skrypt robiłby to co napisałem, a na końcu porównywał
> wyniki z oczekiwanymi (po np. ostatecznym cvs release).
> 
> Dla takiego apacha można by to zrobić, prze uruchomienie go z
> uproszczonym configiem, na jakimś dziwnym porcie i próby ściągnięcia
> wget-em indeksu, pliku, może jakiegoś CGI i sprawdzenia czy jest OK.
> 
> Dla wszelkich interpreterów/kompilatorów test sprawdzałby działanie
> programiku w danym języku.
> 
> Dla ssh stawiałby serwer na dziwnym porcie (jeśli w ogóle jest możliwe
> odpalanie sshd nie z roota) i próbował się zalogować (dla interaktywnego
> logowania przydatny byłby expect).
> 
> itd. itp.

Nie głupie. Potencjalnie cała seria testów musiałaby być wykonywana po
każdym upgrade pakietów.
Środowiska testowe możnaby utrzymywać w osobnych chroot. Na sparc czy
powstajacy wąłsni sparc64 prawie pewnikeim mieć beda miejsce i zasoby żeby
postawić taki system. Chętnych którzy chcieliby urzymywaźć takie
środowiska testowe prosiłbym o zgłaszanie się. W tej chwili u Janka robi
się już dość ciasno, a i dalsze rozpraszanie kolejnego aspektu zwiazanego
z tym co robimy byłoby dość korzystne.

> Tylko trzeba pamiętać że to i tak nigdzy wszystkiego nie przetestuje i
> mogą sie pojawiać błędne pakiety --- tego nigdy nie unikniemy i nie ma
> co zawsze doszukiwać się winnych.

Jasne niemniej przynajmniej jedno jest dla mnie jasne. Tego typu test
powinien być przeprowadzany przed przesunieciem pakietów z test do
podstawowej hierarhii. Czyli np. próba wykonania scp wykazałaby że coś
jest nie tak po upgrade nowym openssl jaki pojawił się kilka dni temu.
Potencjalnie na każdy niemal pakiet możnaby wymyśleć jakaś procedurę
testową.
 
> Jeszcze kwestia techniczna. Wygląda na to że teki test raczej nie będzie
> jednym plikiem. Na pewno część wspólnych funkcji można wydzielić
> (przygotowanie katalogu, porównanie wyniku, wygenerowanie raportu), ale
> i tak taki test będzie się składał z kilku plików (np. skrypt testujący,
> programik wzorcowy i wzorcowy wynik). I nie wiem, czy lepiej robić
> osobne katalogi dla każdego testu, czy po prostu pliki typu: cvs.test,
> cvs.input, cvs.output.

Wydaje mi się, że mam przynajmnie jeden kolejny rodzaj testu jaki w takich
specjalnych środowiskach moznaby przeprowadzić.
Byłoby to w kółko kompilowani tych pakeitów jaki leżą na ftp.
Ten test mógłby być wykonywany niemal permanetnie choć na pewno z niskim
priorytetem.
Pozwoliłoby to np. na automatycne wychwyytywanie tego, że coś sie
przestało kompilować po upgrade jakiegopś pakietu.
Wyży priorytet mogłby mieć testy konkretnych programów czy serwisów.

> Co o tym myślicie?

Dla mnie gucio. Widze przynajmnie już w zarysie kilka rzeczy które możnaby
robić i na pewno maszynki ze środowiskami testowymi nie narzekałyby na
nudę .. wręcz przeciwnie.

Dodatkowo sygnały o nieprawidłowościach ze środowisk testowych powinnyu
automatycznie lądować w bazie BTSa. Przy takim spięciu całosci mamy coś co
pracuje bezobsługowo i niewymaga doglądania w trakcie funkcjonowani
pozwalając skupiać się i angażować konkretnych ludzi tylko w przypadku
nieprawidłowości.

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*