GitHub Actions i .NET

  • Artykuł

W tym omówieniu dowiesz się, jaką rolę odgrywa funkcja GitHub Actions w tworzeniu aplikacji platformy .NET. Funkcja GitHub Actions umożliwia repozytoriom kodu źródłowego automatyzowanie ciągłej integracji i ciągłego dostarczania (CD). Poza tym funkcja GitHub Actions udostępnia bardziej zaawansowane scenariusze — zapewniając punkty zaczepienia na potrzeby automatyzacji dzięki przeglądom kodu, zarządzaniu gałęziami i klasyfikacji problemów. Kod źródłowy platformy .NET w usłudze GitHub umożliwia korzystanie z funkcji GitHub Actions na wiele sposobów.

Funkcja GitHub Actions

Funkcja GitHub Actions reprezentuje autonomiczne polecenia, takie jak:

  • actions/checkout — ta akcja sprawdza repozytorium w obszarze $GITHUB_WORKSPACE, aby przepływ pracy mógł uzyskać do niego dostęp.
  • actions/setup-dotnet — ta akcja konfiguruje środowisko interfejsu wiersza polecenia platformy .NET do użycia w akcjach.
  • dotnet/versionsweeper — ta akcja zamiata repozytoria .NET dla wersji docelowych platformy .NET poza obsługą.

Chociaż te polecenia są izolowane do pojedynczej akcji, są zaawansowane dzięki kompozycji przepływu pracy. W kompozycji przepływu pracy zdefiniujesz zdarzenia , które wyzwalają przepływ pracy. Po uruchomieniu przepływu pracy istnieją różne zadania , które mają być wykonywane. Każde zadanie definiuje dowolną liczbę kroków. Kroki delegują do funkcji GitHub Actions lub alternatywnie wywołają skrypty wiersza polecenia.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do funkcji GitHub Actions. Plik przepływu pracy można traktować jako kompozycję reprezentującą różne kroki tworzenia, testowania i/lub publikowania aplikacji. Dostępnych jest wiele poleceń interfejsu wiersza polecenia platformy .NET, z których większość może być używana w kontekście akcji usługi GitHub.

Niestandardowe akcje GitHub Actions

Chociaż w witrynie Marketplace jest dostępnych wiele funkcji GitHub Actions, możesz chcieć utworzyć własne. Możesz utworzyć funkcję GitHub Actions, która uruchamia aplikacje platformy .NET. Aby uzyskać więcej informacji, zobacz Samouczek: tworzenie akcji usługi GitHub za pomocą platformy .NET

Plik przepływu pracy

Funkcja GitHub Actions jest używana za pośrednictwem pliku przepływu pracy. Plik przepływu pracy musi znajdować się w katalogu .github/workflows repozytorium i powinien być plikiem YAML ( *.yml lub *.yaml). Pliki przepływu pracy definiują kompozycję przepływu pracy. Przepływ pracy to konfigurowalny zautomatyzowany proces składający się z co najmniej jednego zadania. Aby uzyskać więcej informacji, zobacz Składnia przepływu pracy dla funkcji GitHub Actions.

Przykładowe pliki przepływu pracy

Istnieje wiele przykładów plików przepływu pracy platformy .NET dostępnych jako samouczki i przewodniki Szybki start. Oto kilka dobrych przykładów nazw plików przepływu pracy:

Nazwa pliku przepływu pracy

Opis

build-validation.yml

Kompiluje (lub kompiluje) kod źródłowy. Jeśli kod źródłowy nie zostanie skompilowany, zakończy się to niepowodzeniem.

build-and-test.yml

Wykonuje testy jednostkowe w repozytorium. Aby można było uruchamiać testy, należy najpierw skompilować kod źródłowy — jest to naprawdę zarówno przepływ pracy kompilacji, jak i testowania (zastępuje to przepływ pracy build-validation.yml ). Nieudane testy jednostkowe spowodują niepowodzenie przepływu pracy.

publish-app.yml

Pakiety i publikują kod źródłowy w miejscu docelowym.

codeql-analysis.yml

Analizuje kod pod kątem luk w zabezpieczeniach i błędów kodowania. Wszelkie wykryte luki w zabezpieczeniach mogą spowodować niepowodzenie.

Zaszyfrowane wpisy tajne

Aby używać zaszyfrowanych wpisów tajnych w plikach przepływu pracy, odwołujesz się do wpisów tajnych przy użyciu składni wyrażenia przepływu pracy z secrets obiektu kontekstu.

${{ secrets.MY_SECRET_VALUE }} # The MY_SECRET_VALUE must exist in the repository as a secret

Wartości wpisów tajnych nigdy nie są drukowane w dziennikach. Zamiast tego ich nazwy są drukowane gwiazdką reprezentującą ich wartości. Na przykład, gdy każdy krok jest uruchamiany w ramach zadania, wszystkie używane wartości są danymi wyjściowymi dziennika akcji. Wartości wpisów tajnych są renderowane podobnie do następujących:

MY_SECRET_VALUE: ***

Ważne

Kontekst secrets zawiera token uwierzytelniania usługi GitHub, który jest przeznaczony dla repozytorium, gałęzi i akcji. Jest ona dostarczana przez usługę GitHub bez żadnej interwencji użytkownika:

${{ secrets.GITHUB_TOKEN }}

Aby uzyskać więcej informacji, zobacz Używanie zaszyfrowanych wpisów tajnych w przepływie pracy.

Zdarzenia

Przepływy pracy są wyzwalane przez wiele różnych typów zdarzeń. Oprócz zdarzeń elementu webhook, które są najbardziej typowe, istnieją również zaplanowane zdarzenia i zdarzenia ręczne.

Przykładowe zdarzenie elementu webhook

W poniższym przykładzie pokazano, jak określić wyzwalacz zdarzenia elementu webhook dla przepływu pracy:

name: code coverage

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main, staging

jobs:
  coverage:

    runs-on: ubuntu-latest

    # steps omitted for brevity

W poprzednim przepływie pracy zdarzenia push i pull_request wyzwolą przepływ pracy do uruchomienia.

Przykład zaplanowanego zdarzenia

W poniższym przykładzie pokazano, jak określić wyzwalacz zdarzenia zaplanowanego (zadania cron) dla przepływu pracy:

name: scan
on:
  schedule:
  - cron: '0 0 1 * *'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    # steps omitted for brevity

W poprzednim przepływie pracy zdarzenie określacron, schedule z '0 0 1 * *' którego będzie wyzwalany przepływ pracy uruchamiany w pierwszym dniu każdego miesiąca. Uruchamianie przepływów pracy zgodnie z harmonogramem jest doskonałe dla przepływów pracy, które wymagają dużo czasu do uruchomienia lub wykonywania akcji, które wymagają mniej częstej uwagi.

Przykładowe zdarzenie ręczne

W poniższym przykładzie pokazano, jak określić wyzwalacz zdarzenia ręcznego dla przepływu pracy:

name: build
on:
  workflow_dispatch:
    inputs:
      reason:
        description: 'The reason for running the workflow'
        required: true
        default: 'Manual run'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: 'Print manual run reason'
        if: ${{ github.event_name == 'workflow_dispatch' }}
        run: |
          echo 'Reason: ${{ github.event.inputs.reason }}'

    # additional steps omitted for brevity

W poprzednim przepływie pracy workflow_dispatch zdarzenie wymaga reason jako danych wejściowych. Usługa GitHub widzi to i jego interfejs użytkownika dynamicznie zmienia się, aby monitować użytkownika o podanie przyczyny ręcznego uruchamiania przepływu pracy. Element steps wyświetli podaną przyczynę od użytkownika.

Aby uzyskać więcej informacji, zobacz Zdarzenia wyzwalające przepływy pracy.

.NET CLI

Interfejs wiersza polecenia platformy .NET to wieloplatformowy łańcuch narzędzi do tworzenia, kompilowania, uruchamiania i publikowania aplikacji .NET. Interfejs wiersza polecenia platformy .NET jest używany do run pojedynczego steps elementu w pliku przepływu pracy. Typowe polecenie to:

Aby uzyskać więcej informacji, zobacz Omówienie interfejsu wiersza polecenia platformy .NET

Zobacz też

Aby uzyskać bardziej szczegółowe omówienie funkcji GitHub Actions na platformie .NET, rozważ następujące zasoby: