tests implementation

Opis

Fajnie fajnie ale gdzie są testy?

Opis proponowanych testów

Z uwagi na fakt że rola ta jest dość specyficzna proponuje co następuje:

1. Nie testujemy akcji w całości, pierwsze uruchomienie musi się odbyć lokalnie przez użytkownika i będzie do tego notka w readme jak to zrobić (może skrypt)

2. Patrząc na aktualne API roli https://projects.task.gda.pl/ansible-roles/certbot/-/tree/4-tests-implementation#variables proponuje aby w pierwszej wersji testować:

   • dwa systemy: centos-7 i ubuntu-focal,
   • dwa testy:
     • pierwszy bez s3 (i tak będziemy przechowywać w s3 ale synchronizować będziemy się w before i after skrypcie sami)
     • drugi z s3
   • testy będą typu scheduled, uruchamiane co powiedzmy 5 dni (aby nie utracić ważności raz wpisanych rekodów TXT do DNS'a)
   • testy będą sprawdzać czy serwis zadziałał (manipulując czasem poprzez zmienną od timera, będą czekać na pierwsze uruchomienie serwisu (zrobimy timer co 1 minute)) następnie wyłączymy timer aby nie uruchamiał się wiele razy
   • pod koniec testy będą sprawdzać prawidłoœść powstałych plików (czy chain ok, czy full chain i cert mają odpowiednio długą ważność, czy klucz pasuje do certa)

3. Nie chce się na tym etapie rozdrabniać na testowanie absolutnie wszystkiego jak serwis name, itp, mamy dokładnie dwa przypadki użycia z s3 i bez s3 i tak na początek będzie najłatwiej

4. W testach chce użyć następujących domen:

   • "test01.certbot.{{ ansible_distribution | lower }}.task.gda.pl" i "alt.test01.certbot.{{ ansible_distribution | lower }}.task.gda.pl"
   • "test02.certbot.{{ ansible_distribution | lower }}.task.gda.pl"

   czyli łącznie 6 domen, po trzy na każdy z systemów.

EDIT - 25.07.2022

Redesign testów wynikający z wprowadzonej automatyzacji DNS challenge

Jako konsekwencja #7 (closed), design testów także musi zostać zaktualizowany. MR !4 (merged) będzie zbiorczy dla testów.

Aby certbot nie przeszkadzał sobie podczas wykonywania tych samych testów równolegle na różnych systemach, jedną drogą byłoby użycie speccyficznych domen (jak wyżej). Postanowiłem jednak rozbić poszczególne systemy operacyjne na osobne stage. IMO jest wtedy czytelniej i nie robi sie nadmierny śmietnik (nie trzeba tez dodawac osobnego CNAME dla kazdego systemu osobno).

Zaktualizowana lista przypadków:

1. przypadek minimalny wykorzystanie produkyjnego ACME [#8 (closed)]
2. przypadek minimalny z uzyciem testowego servera (podobnie wszsystkie kolejne testy) [#9 (closed)]
3. przypadek z kilkoma domenami oraz z domenami z różnych zon [#10 (closed)]
4. przypadek z kilkoma domenami (jedna z nich z wildcardem) [#11 (closed)]
5. przypadek z aliasem [#12 (closed)]
6. synchronizacja z s3 - upload wygenerowanego certyfikatu [#13 (closed)]
7. synchronizacja z s3 - download aktualnego certyfikatu [#14 (closed)]
8. synchronizacja z s3 - download nieaktualnego certyfikatu, odnowienie i upload [#15 (closed)]
9. kopiowanie plików lokalnie po generacji certyfikatu [#16 (closed)]
10. komenda wykonywana po generacji certyfikatu [#17 (closed)]
11. odnowienie certyfikatu [#20 (closed)]
12. idempotentność [#22 (closed)]