Jak używać funkcji GitHub Actions do tworzenia przepływów pracy dla ciągłej integracji?

Ukończone

Tutaj dowiesz się o GitHub Actions i przepływach pracy dla CI.

Dowiesz się, jak wykonywać następujące działania:

• Tworzenie przepływu pracy na podstawie szablonu
• Zrozumienie dzienników GitHub Actions
• Testowanie pod kątem wielu obiektów docelowych
• Oddzielne zadania kompilacji i testowania
• Zapisywanie artefaktów kompilacji i uzyskiwanie do ich dostępu
• Automatyzować etykietowanie pull requestów w trakcie przeglądu

Tworzenie przepływu pracy na podstawie szablonu

Aby utworzyć przepływ pracy, zacznij od użycia szablonu. Szablon zawiera typowe zadania i kroki wstępnie skonfigurowane dla określonego typu implementowanej automatyzacji. Jeśli nie znasz przepływów pracy, zadań i kroków, zapoznaj się z modułem Automate development tasks by using GitHub Actions module (Automatyzowanie zadań programistycznych przy użyciu funkcji GitHub Actions).

Na stronie głównej repozytorium wybierz kartę Akcje, a następnie wybierz pozycję Nowy przepływ pracy.

Na stronie Wybierz przepływ pracy możesz wybrać spośród wielu różnych szablonów. Przykładem jest szablon Node.js, który wykonuje czystą instalację zależności Node, kompiluje kod źródłowy i uruchamia testy dla różnych wersji Node. Innym przykładem jest szablon pakietu języka Python, który instaluje zależności języka Python i uruchamia testy, w tym lint, w różnych wersjach języka Python.

W polu wyszukiwania wprowadź Node.js.

W wynikach wyszukiwania w okienku Node.js wybierz opcję Konfiguruj.

Ten domyślny przepływ pracy szablonu Node.js zostanie wyświetlony w nowo utworzonym pliku node.js.yml.

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

Zwróć uwagę na atrybut on:. Ten przepływ pracy jest wyzwalany podczas wprowadzenia zmian do repozytorium oraz gdy zostanie złożone żądanie scalenia względem gałęzi głównej.

W tym przepływie pracy znajduje się jeden job. Sprawdźmy, co to robi.

Atrybut runs-on: określa, że dla systemu operacyjnego przepływ pracy jest uruchamiany w ubuntu-latest. Atrybut node-version: określa, że są trzy kompilacje, każda dla wersji Node 14.x, 16.x i 18.x. Szczegółowo opiszemy część matrix później, gdy dostosujemy przepływ pracy.

steps w zadaniu używają akcji GitHub Actions actions/checkout@v3 w celu pobrania kodu z repozytorium do maszyny wirtualnej oraz akcji actions/setup-node@v3 w celu skonfigurowania odpowiedniej wersji Node.js. Określamy, że będziemy testować trzy wersje Node.js za pomocą atrybutu ${{ matrix.node-version }}. Ten atrybut odwołuje się do wcześniej zdefiniowanej macierzy. Atrybut cache określa menedżera pakietów do buforowania w katalogu domyślnym.

Ostatnia część tego kroku wykonuje polecenia używane przez projekty Node.js. Polecenie npm ci instaluje zależności z pliku package-lock.json, npm run build --if-present uruchamia skrypt kompilacji, jeśli istnieje, a npm test uruchamia platformę testowania. Zwróć uwagę, że ten szablon zawiera zarówno kroki kompilacji, jak i testu w tym samym zadaniu.

Aby dowiedzieć się więcej na temat narzędzia npm, zapoznaj się z dokumentacją narzędzia npm:

• instalacji narzędzia npm
• uruchamiania narzędzia npm
• npm test

Dzienniki operacji dla budowania

Po uruchomieniu przepływu pracy tworzony jest dziennik zawierający szczegółowe informacje o tym, co się wydarzyło, oraz wszelkie błędy lub niepowodzenia testów.

Jeśli wystąpi błąd lub test zakończy się niepowodzeniem, w logach zostanie wyświetlony czerwony ✖, a nie zielony znacznik ✔. Możesz sprawdzić szczegóły błędu lub awarii, aby zbadać, co się stało.

W ćwiczeniu zidentyfikujesz testy, które zakończyły się niepowodzeniem, sprawdzając szczegóły w dziennikach. Dostęp do dzienników można uzyskać na karcie Actions.

Dostosowywanie szablonów przepływów pracy

Na początku tego modułu opisaliśmy scenariusz, w którym musisz skonfigurować CI dla swojego zespołu. Szablon Node.js to doskonały początek, ale chcesz dostosować go do własnych wymagań zespołu. Chcesz skierować się na różne wersje Node i różne systemy operacyjne. Chcesz również, aby kroki kompilacji i testowania byłyby oddzielnymi zadaniami.

Przyjrzyjmy się, jak dostosować przepływ pracy.

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

W tym miejscu skonfigurowaliśmy macierz kompilacji do testowania w wielu systemach operacyjnych i wersjach językowych. Ta macierz tworzy cztery kompilacje, po jednym dla każdego systemu operacyjnego sparowanego z każdą wersją środowiska Node.

Cztery kompilacje, wraz ze wszystkimi testami, generują sporo logów. Może być trudno to wszystko uporządkować. W poniższym przykładzie pokazano, jak przenieść krok testu do dedykowanego zadania testowego. To zadanie testuje pod kątem wielu obiektów docelowych. Oddzielenie kroków kompilacji i testowania ułatwia zrozumienie dziennika.

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true

Co to są artefakty?

Gdy przepływ pracy generuje coś innego niż wpis dziennika, produkt jest nazywany artefaktem . Na przykład kompilacja Node.js tworzy kontener platformy Docker, który można wdrożyć. Ten artefakt, kontener, można przekazać do przechowywania przy użyciu akcji actions/upload-artifact i później pobrać z przechowywania przy użyciu akcji actions/download-artifact.

Przechowywanie artefaktu zachowuje go między zadaniami. Każde zadanie używa nowego wystąpienia maszyny wirtualnej, więc nie można ponownie użyć artefaktu, zapisując go na maszynie wirtualnej. Jeśli potrzebujesz artefaktu w innym zadaniu, możesz przekazać artefakt do magazynu w jednym zadaniu i pobrać go dla drugiego zadania.

Magazyn artefaktów

Artefakty są przechowywane w miejscu do magazynowania w usłudze GitHub. Miejsce jest bezpłatne dla repozytoriów publicznych, a część jest bezpłatna dla repozytoriów prywatnych, w zależności od konta. Usługa GitHub przechowuje artefakty przez 90 dni.

W poniższym fragmencie przepływu pracy zwróć uwagę, że w akcji actions/upload-artifact@main znajduje się atrybut path:. Wartość tego atrybutu to ścieżka do przechowywania artefaktu. W tym miejscu wskazujemy public/, aby przenieść wszystko do katalogu. Gdybyśmy chcieli przesłać pojedynczy plik, moglibyśmy użyć czegoś takiego jak public/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Aby pobrać artefakt do testowania, kompilacja musi zakończyć się pomyślnie, a następnie artefakt powinien zostać przekazany. W poniższym kodzie określamy, że zadanie testowe zależy od zadania kompilacji.

test:
    needs: build
    runs-on: ubuntu-latest

W poniższym fragmencie przepływu pracy pobierzemy artefakt. Teraz zadanie testowe może używać artefaktu do testowania.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

Aby uzyskać więcej informacji na temat używania artefaktów w przepływach pracy, zobacz Przechowywanie danych przepływu pracy jako artefakty w dokumentacji usługi GitHub.

Automatyzowanie przeglądów w usłudze GitHub przy użyciu przepływów pracy

Do tej pory opisano uruchamianie przepływu pracy ze zdarzeniami w GitHubie, takimi jak push lub pull request. Możemy również uruchomić przepływ pracy zgodnie z harmonogramem lub na jakimś zdarzeniu poza usługą GitHub.

Czasami chcemy uruchomić przepływ pracy dopiero po wykonaniu akcji przez osobę. Na przykład możemy chcieć uruchomić przepływ pracy tylko wtedy, gdy recenzent zatwierdzi żądanie ściągnięcia. W tym scenariuszu możemy uruchomić pull-request-review.

Kolejną akcją, którą możemy wykonać, jest dodanie etykiety do żądania ściągnięcia. W tym przypadku używamy akcji pullreminders/label-when-approved-action.

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

Zwróć uwagę na blok o nazwie env:. Ten blok służy do ustawiania zmiennych środowiskowych dla tej akcji. Można na przykład ustawić wymaganą liczbę osób zatwierdzających. Oto jeden. Wymagana jest zmienna uwierzytelniania secrets.GITHUB_TOKEN, ponieważ akcja musi wprowadzać zmiany w repozytorium przez dodanie etykiety. Na koniec należy podać nazwę etykiety do dodania.

Dodanie etykiety może być zdarzeniem, które uruchamia inny przepływ pracy, na przykład scalanie. To zdarzenie zostało omówione w następnym module dotyczącym ciągłego dostarczania za pomocą funkcji GitHub Actions.