Jak mogę tworzyć przepływy pracy na potrzeby CI za pomocą funkcji GitHub Actions?

Ukończone

Tutaj poznasz funkcję GitHub Actions i przepływy pracy wymagane do wdrożenia CI.

Dowiedz się, jak odbywa się:

• Tworzenie przepływu pracy na podstawie szablonu
• Korzystanie z dzienników funkcji GitHub Actions
• Testowanie pod kątem wielu elementów docelowych
• Oddzielanie zadań kompilacji i testowania
• Zapisywanie artefaktów kompilacji i uzyskiwanie do niech dostępu
• Automatyzowanie dodawania etykiet do żądań ściągnięcia podczas przeglądu kodu

Tworzenie przepływu pracy na podstawie szablonu

Możesz utworzyć przepływ pracy, zaczynając od 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 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 Wybieranie przepływu 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 węzła, kompiluje kod źródłowy i uruchamia testy dla różnych wersji środowiska 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 pozycję 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 wypychania do repozytorium, a po wysłaniu żądania ściągnięcia względem gałęzi głównej.

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

Atrybut runs-on: określa, że przepływ pracy jest uruchamiany w systemie operacyjnym ubuntu-latest. Atrybut node-version: określa, że istnieją trzy kompilacje, po jednym dla węzła w wersji 14.x, 16.x i 18.x. Szczegółowo opiszemy matrix część później, gdy dostosujemy przepływ pracy.

W steps zadaniu użyj akcji GitHub Actions /checkout@v3 , aby pobrać kod z repozytorium do maszyny wirtualnej, oraz akcję 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 służy do wykonania poleceń używanych w projektach Node.js. Polecenie npm ci instaluje zależności z pliku package-lock.json, polecenie npm run build --if-present uruchamia skrypt kompilacji (jeśli taki istnieje), a polecenie npm test uruchamia strukturę testowania. Zwróć uwagę, że w tym szablonie kroki kompilacji i testowania znajdują się w tym samym zadaniu.

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

• npm install
• npm run
• npm test

Dzienniki akcji dla kompilacji

Po uruchomieniu przepływu pracy jest generowany dziennik zawierający szczegóły wykonanych czynności oraz informacje o ewentualnych błędach lub niepowodzeniach testów.

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

Podczas wykonywania ćwiczenia określisz, które testy zakończyły się niepowodzeniem, sprawdzając szczegóły w dziennikach. Możesz uzyskać dostęp do dzienników z poziomu karty Actions.

Dostosowywanie szablonów przepływów pracy

Na początku tego modułu opisano scenariusz, w którym należy skonfigurować ciągłą integrację dla zespołu. Szablon Node.js to doskonały początek, ale chcesz dostosować go do własnych wymagań zespołu. Chcesz określić różne wersje docelowe środowiska Node i różne systemy operacyjne. Chcesz również, aby kroki kompilacji i testowania byłyby oddzielnymi zadaniami.

Zobaczmy, jak można dostosować przepływ pracy.

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

Skonfigurowaliśmy macierz kompilacji na potrzeby testowania pod kątem różnych systemów operacyjnych i różnych wersji języka. 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 informacji dziennika. Może być trudno przez to wszystko przebrnąć. W poniższym przykładzie pokazano, jak przenieść krok testu do dedykowanego zadania testowego. To zadanie umożliwia testowanie pod kątem wielu elementó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 magazynu przy użyciu akcji actions/upload-artifact i później pobrane z magazynu przy użyciu akcji actions/download-artifact.

Przechowywanie artefaktu zachowuje je 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 magazynie w usłudze GitHub. Magazyn jest bezpłatny w przypadku repozytoriów publicznych, a w przypadku repozytoriów prywatnych bezpłatna jest określona ilość miejsca w magazynie, w zależności od konta. Usługa GitHub przechowuje artefakty przez 90 dni.

W poniższym fragmencie kodu przepływu pracy zwróć uwagę, że w actions/upload-artifact@main akcji istnieje path: atrybut. Wartość tego atrybutu to ścieżka do przechowywania artefaktu. Tutaj określamy wartość public/, aby wszystko było przekazywane do katalogu. Jeśli chcemy przekazać pojedynczy plik, użyjemy czegoś takiego jak publiczny/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 i przekazać artefakt. 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 artefakt może być używany do testów w ramach zadania 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 artefaktów w dokumentacji usługi GitHub.

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

Do tej pory opisano uruchamianie przepływu pracy z zdarzeniami usługi GitHub, takimi jak wypychanie lub żądanie ściągnięcia. 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 po zatwierdzeniu żądania ściągnięcia przez recenzenta. W takiej sytuacji możemy wyzwolić przepływ pracy przy użyciu zdarzenia pull-request-review.

Inną akcją, którą możemy wykonać, jest dodanie etykiety do żądania ściągnięcia. W takim przypadku użyjemy 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. W tym przypadku jest to jedna osoba. Zmienna uwierzytelniania jest wymagana secrets.GITHUB_TOKEN , ponieważ akcja musi wprowadzać zmiany w repozytorium, dodając etykietę. 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.