Uzgodnienie konfiguracji Github Actions z developerską

[lgpawel]

Już co najmniej dwa razy automatyczne aktualizacje wersji pakietów, od których zależy nasz projekt, sprawiły, że na master-dev lądowała konfiguracja, która nie chciała się uruchomić, mimo że żądane checki przechodziły. Problemy dotyczyły pakietów xhtml2pdf (tu kartą wyjścia z więzienia było usunięcie go z zależności, bo już dawno przestał być realnie wykorzystywany w projekcie, por. #1607) czy niedawno w sass – tu nie ma póki co ładnego rozwiązania; hotfixem była ręczna degradacja pakietu do ostatniej wspieranej wersji (co powtarzało się kilka razy, kiedy Renovate dowiadywał się o pojawieniu się jeszcze nowszej wersji), obecnie pakiet jest na "czarnej liście" w pliku konfiguracyjnym .github/renovate.json ale to naturalnie bardzo ryzykowne zamiatanie realnego problemu pod dywan.

A realnym problemem jest to, że konfiguracja "developerska" maszyny wirtualnej etc. nie odpowiada dobrze (choć powinna odpowiadać 1:1) maszynie, na której GitHub odpala swoje Actions, więc zdarza się, że kroki, które tam przechodzą, nie przechodzą "u nas". Actions konfigurowane są w .github/workflows za pomocą playbooków Ansible'a (a w każdym razie łudząco do nich podobnych), podobnie jak środowisko developerskie (w infra/playbooks/dev).

Oczywiście podobieństwa między playbookami mogą być dość ograniczone, ale jednak należy się przyjrzeć temu, gdzie występują kluczowe różnice, a także, jakie możliwości wyboru (np. obrazu VM) oferuje nam GitHub, i co wybieramy obecnie, a co powinniśmy. Może się okazać, że rozwiązanie problemu wymaga nietrywialnych zmian w konfiguracji developerskiej (np. takich, o które należy powalczyć przy #1748), wtedy naturalnie należałoby je uwzględnić.

Innym powiązanym tematycznie issue jest #1683. Na koniec dobrze byłoby nie zapomnieć o przywróceniu normalnej obsługi aktualizacji sass.