GitHub Actions i .NET

Artykuł
01/07/2025

W tym omówieniu dowiesz się, jaką rolę GitHub Actions odgrywają w tworzeniu aplikacji .NET. GitHub Actions umożliwiają repozytoriom kodu źródłowego automatyzowanie ciągłej integracji (CI) 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.

GitHub Actions

Funkcja GitHub Actions reprezentuje autonomiczne polecenia, takie jak:

akcje/wyewidencjonowywanie — ta akcja sprawdza repozytorium w obszarze $GITHUB_WORKSPACE, aby przepływ pracy mógł uzyskać do niego dostęp.
actions/setup-dotnet — akcja ta konfiguruje środowisko .NET CLI do użycia w akcjach.
dotnet/versionsweeper — to działanie przeszukuje repozytoria .NET w poszukiwaniu przestarzałych wersji docelowych .NET.

Chociaż te polecenia są izolowane do pojedynczej akcji, są potężne poprzez kompozycję 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ą zadania do GitHub Actions lub wywołują skrypty wiersza polecenia.

Aby uzyskać więcej informacji, zobacz Introduction to 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

Chociaż w witrynie Marketplace jest dostępnych wiele Akcji GitHub, możesz chcieć utworzyć swoje własne. Możesz utworzyć funkcję GitHub Actions, która uruchamia aplikacje platformy .NET. Aby uzyskać więcej informacji, zobacz Tutorial: Create a GitHub Action with .NET(Samouczek: tworzenie akcji GitHub z użyciem .NET).

Plik przepływu pracy

GitHub Actions są wykorzystywane za pomocą pliku roboczego. 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 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 szybkiego startu . Oto kilka dobrych przykładów nazw plików przepływu pracy:

Nazwa pliku przepływu pracy

opis

build-validation.yml

Kompiluje (lub buduje) 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, najpierw należy 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 przebiegu pracy.

publish-app.yml

Pakuje i publikuje kod źródłowy do miejsca docelowego.

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żyć zaszyfrowanych sekretów w plikach przepływu pracy, należy odwołać się do sekretów przy użyciu składni wyrażenia przepływu pracy z obiektu kontekstusecrets.

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

Tajne wartości nigdy nie są zapisywane 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 tajne wyglądają podobnie do następujących:

MY_SECRET_VALUE: ***

Ważny

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

${{ secrets.GITHUB_TOKEN }}

Aby uzyskać więcej informacji, zobacz Używanie zaszyfrowanych sekretów w procesie roboczym.

Zdarzenia

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

Przykładowe zdarzenie webhook

W poniższym przykładzie pokazano, jak określić wyzwalacz zdarzenia 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 spowodują jego uruchomienie.

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 schedule określa cron'0 0 1 * *', które uruchomi przepływ pracy pierwszego dnia 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 zdarzenie workflow_dispatch wymaga reason jako danych wejściowych. GitHub zauważa to i jego interfejs użytkownika dynamicznie zmienia się, aby zachęcić użytkownika do podania przyczyny ręcznego uruchomienia przepływu pracy. steps wyświetli przyczynę przekazaną przez użytkownika.

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

Interfejs wiersza polecenia platformy .NET

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 w ramach poszczególnych steps w pliku przepływu pracy. Typowe polecenia obejmują:

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:

Udostępnij za pośrednictwem