Github Actions – budowa i testowanie aplikacji

W dzisiejszym wpisie pokażę przykład w jaki sposób zbudować i przetestować aplikację napisaną w wykorzystaniem Node.JS oraz React (Create React App).

Spis treści

1. Zaczynamy
2. Struktura pliku
3. Gotowy plik na zbudowanie przetestowanie i zbudowanie aplikacji React z wykorzystaniem Create React App.
4. Analiza pliku yml
5. Gotowy plik na zbudowanie przetestowanie i zbudowanie aplikacji Node.JS
6. Podsumowanie

Zaczynamy

Zdefiniowanie nowej akcji jest bardzo proste. Musimy mieć utworzone repozytorium na Githubie (to chyba jasne, prawda? 😉). Nie ma różnicy, czy publiczny czy prywatne. Następnie tworzymy plik yml o dowolnej nazwie w katalogu .github/workflows .

Struktura pliku

Możliwości jest bardzo dużo (dokumentacja), a ja pokażę tylko najprostsze opcje, które pozwolą nam stworzyć pierwsze automaty.

Aktualnie wykorzystuję 3 (4) główne:

1. name – nazwa workflow
2. on – zdarzenie, kiedy uruchamiana jest akcja
3. jobs – zdanie lub zdania do wykonania
4. defaults (opcjonalnie) – domyślne wartości

Gotowy plik na zbudowanie przetestowanie i zbudowanie aplikacji React z wykorzystaniem Create React App.

name: Client build and test

on:
  push:
    branches:
      - dev

defaults:
  run:
    working-directory: ./client

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    strategy:
      matrix:
        node-version: [ 14.x ]
#        node-version: [ 10.x, 12.x, 14.x ]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

      - name: Install dependencies
        run: npm install

      - name: Run linter
        run: npm run lint

      - name: Run unit tests
        run: npm test
        env:
          CI: true

      - name: Build application
        run: npm build

Analiza pliku

Linijka 1
Nazwa naszego workflow

Linijka 3-6
Definicja wyzwolenia akcji (dokumentacja). W moim przypadku jest to push kodu na branchu dev.

Linijka 8-10
Ustawienie domyślnego working directory dla poleceń run. Dzięki temu dla każdego kroku nie będę musiał ustawiać katalogu w jakim ma wykonać polecenie.

Linijka 12-40
Definicja zadań. W moim workflow wykorzystuje tylko jeden job, który jest podzielony na kroki.

Linijka 14
Definiujemy gdzie nasze zadania zostaną wykonane. Możemy wybrać systemy oferowane przez Github wykorzystując darmowe lub płatne minuty lub uruchomić na własnym runnerze.

Linijka 15
Maksymalny czas wykonania workflow. Dlaczego warto ustawić ten parametr? Więcej tutaj.

Linijka 16-19
Ciekawa opcja dla osób, które tworzą własne biblioteki. Możemy zdefiniować na jakich wersjach Node’a mają zostać wykonane. Bardzo ważne! Uruchamiając na kilku wersjach Node’a zużywamy odpowiednio więcej zasobów minutowych.

Linijka 21-40
Definicja poszczególnych kroków. Tutaj zaczyna się dowolność i definicja tego co potrzebuje aplikacja. Każdy krok do jeden klocek do osiągnięcia naszego celu. Github oferuje marketplace, gdzie możemy skorzystać z gotowych rozwiązań potrzebnych do budowy, deploymentu czy raportowania.
Myślę, że nie będę opisywał poszczególnych kroków. Są dość czytelne 🙂

Gotowy plik na zbudowanie przetestowanie i zbudowanie aplikacji Node.JS

name: Api build and test

on:
  push:
    branches:
      - dev

defaults:
  run:
    working-directory: ./api

jobs:
  build:
    runs-on: self-hosted
    timeout-minutes: 15
    strategy:
      matrix:
        node-version: [ 14.x ]
#        node-version: [ 10.x, 12.x, 14.x ]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

      - name: Install dependencies
        run: npm install

      - name: Run linter
        run: npm run lint

      - name: Run unit tests
        run: npm run test
        env:
          CI: true

      - name: Build application
        working-directory: ./api
        run: npm build

Linijka 36-37
Możemy przekazać zmienne środowiskowe bezpośrednio do polecenia wykonywanego przez run.

Podsumowanie

Jak widać definiowane workflow z Githuba wcale nie jest takie trudne 🙂 Wymaga to oczywiście cierpliwości, testowania i dostosowywania. Jednak raz poświęcony czas na automatyzację

• Github Actions czy Jenkins? Czy warto korzystać z Github Actions?
• Github Actions – budowa i testowanie aplikacji
• Github Actions – budowa obrazów Dockerowych i wrzucenie ich do repozytorium
• Github Actions – self-hosted runner