Detect pending changes of front-end

[ad-m]

No description provided.

[ad-m]

@rwakulszowa , może krokiem w kierunku testów front-endu jest doprowadzenie tego PR-a do końca? Wymaga upewnienia się (ręcznego), że wszystko po zbudowaniu jest takie jak powinno być (znasz incydent z fedrowania). Przy okazji można wypisać co mogłoby się zepsuć i co trzeba testować. Wówczas będziemy mogli – podobnie jak w Fedrowaniu – zaktualizować dużą część bibliotek front-end dość bezpiecznie. Nie ma po co testować front-endu, skoro front-end nie jest zmieniany, bo strach.

[rwakulszowa]

Jasne, jak najbardziej. Rozumiem, że (w mocnym skrócie), po dodaniu tego wymagania, żeby przepchnąć jakąkolwiek zmianę trzeba najpierw zaktualizować frontend, tak?

Generalnie jestem za. Wczoraj budowałem lokalnie poradnię i faktycznie pojawiły się problemy, które rozwiązała aktualizacja zależności.

Czy publikacja na produkcję dzieje się automatycznie (np. cyklicznie), czy jest to ręczny proces?

[ad-m]

Ręczny proces, ale zautomatyzowany do jednego polecenia.

[ad-m]

Zmiana ma na celu zagwarantowanie, że stan źródeł dla front-endu odpowiada zbudowanemu front-endowi, skoro już go trzymamy w repozytorium. Zagwarantowanie tego nie powinno być trudne, bo build powinien być deterministyczny, zwłaszcza jak będziemy mieli dokładnie opisane zależności (istotny jest package-lock.json dla zależności zależności). W naszym bundlu front-endu mamy trochę rzeczy z paczek Python wyciągany, więc to nas zabezpieczy przed niepostrzeżonym zdesynchronizowaniem scommitowanego bundla przy okazji aktualiczki paczki Python / paczki npm / innej zależności front-end.