Pomiń pakiet internetowy podczas testowania

Porozmawiajmy o pozbyciu się NodeJS z potoków CI.

Prowadzę Chipper CI (ciągła integracja dla Laravela). Zawsze denerwowało mnie, że kompilacje Webpack zajmują więcej czasu i powodują więcej problemów niż rzeczywista cenna część potoku CI.

Większość z nas musi po prostu przeprowadzić testy i być może rozpocząć wdrożenie.Zadania budowania węzłów wydłużają czas i wymagają znacznie większego wykorzystania procesora/RAM.

Co by było, gdybyśmy po prostu nie potrzebowali węzła w naszym potoku? Czy możemy po prostu… nie?

Odpowiedź brzmi: Zdecydowanie, może!

Testy funkcji

Bardzo często jedynym powodem budowania statycznych zasobów w potoku CI jest wygenerowanie pliku mix-manifest.json.

Dzięki temu helper mix() może działać podczas uruchamiania testów funkcji Laravela. Testy funkcji wykonują wywołania HTTP w Twojej aplikacji, a tym samym często renderują szablony bloków, które używają pomocnika mix().

Jeśli nie masz pliku manifestu, zostanie zgłoszony błąd!

Generowanie tego pliku manifestu obejmuje budowanie zasobów statycznych — innymi słowy użycie npm (lub przędzy) do instalowania zależności i uruchamiania zadań Webpack:

# Build static assets
 
npm ci --no-audit
npm run dev

Uwaga: prawie na pewno powinieneś zastosować package-lock.json i uruchomienie npm ci --no-audit zamiast npm install!

Jeśli spojrzysz na swój plik public/mix-manifest.json, prawdopodobnie wygląda on mniej więcej tak (z haszami lub bez, w zależności od tego, czy włączono wersjonowanie):

{
    "/js/app.js": "/js/app.js",
    "/js/foo.js": "/js/foo.js",
    "/css/app.css": "/css/app.css"
}

Oto kicker: niekoniecznie potrzebujesz tego pliku do swoich testów!

W ramach metody setUp() testu możesz dodać następującą magię:

protected function setUp(): void
{
    parent::setUp();
 
    $this->withoutMix();
}

Mając to na miejscu, helper mix() nie zwróci żadnych błędów z brakującym plikiem manifestu. Twoje testy mogą przejść bez konieczności uruchamiania zadań NodeJS!

Inną rzeczą, jaką możesz zrobić, jest utworzenie pliku manifestu dla potoku CI, który kopiujesz do testowania.

Powiedzmy, że nasza konfiguracja Mix generuje powyższy plik mix-manifest.json. Możemy zatwierdzić fikcyjny plik manifestu do tests/mix-manifest.json i zawsze będzie on dostępny!

Następnie, w naszych skryptach potoku CI, możemy użyć tego pliku zamiast instalować/budować nasze zależności węzła:

# What if we created a mix-manifest.json file just for testing?
# During CI, we can just move it where it needs to go
cp tests/mix-manifest.json public/mix-manifest.json
 
# And then run your tests, no NodeJS required!
php artisan test

Mając ten plik na miejscu, pomocnik mix() będzie działał, a testy funkcji mogą przejść bez problemu!

Ta (lub jakakolwiek inna metoda!), która tworzy poprawny plik manifestu, może pomóc Ci zaoszczędzić DUŻO czasu i zasobów serwera w potokach kompilacji CI.

Musisz zaktualizować plik tests/mix-manifest.json za każdym razem, gdy zmienisz konfigurację w sposób, który dodaje pliki do rzeczywistego pliku manifestu.

Kiedy trzeba budować zasoby?

Czasami musisz zbudować zasoby w swoim potoku CI! Oto najczęstsze sytuacje, w których musisz:

1. When you build production assets to bundle them up into an “artifact” (zip file, container image, etc) that you can deploy
2. When you run other node commands as part of your test suite, such as eslint
3. When you are browser testing with Laravel Dusk

A co jeśli muszę budować zasoby?