Udostępnij za pośrednictwem


Szybki start: tworzenie przepływu pracy weryfikacji kompilacji w usłudze GitHub

W tym przewodniku Szybki start dowiesz się, jak utworzyć przepływ pracy usługi GitHub w celu zweryfikowania kompilacji kodu źródłowego platformy .NET w usłudze GitHub. Kompilowanie kodu platformy .NET jest jednym z najbardziej podstawowych kroków weryfikacji, które można wykonać, aby zapewnić jakość aktualizacji kodu. Jeśli kod nie kompiluje (lub kompiluje), jest to łatwy odstraszający element i powinien być wyraźnym znakiem, że kod musi zostać naprawiony.

Wymagania wstępne

  • Konto usługi GitHub.
  • Repozytorium kodu źródłowego platformy .NET.

Tworzenie pliku przepływu pracy

W repozytorium GitHub dodaj nowy plik YAML do katalogu .github/workflows . Wybierz zrozumiałą nazwę pliku, co wyraźnie wskaże, co ma zrobić przepływ pracy. Aby uzyskać więcej informacji, zobacz Plik przepływu pracy.

Ważne

Usługa GitHub wymaga, aby pliki kompozycji przepływu pracy zostały umieszczone w katalogu .github/workflows .

Pliki przepływu pracy zwykle definiują kompozycję co najmniej jednej akcji usługi GitHub za pośrednictwem elementu jobs.<job_id>/steps[*]. Aby uzyskać więcej informacji, zobacz Składnia przepływu pracy dla funkcji GitHub Actions.

Utwórz nowy plik o nazwie build-validation.yml, skopiuj i wklej do niego następującą zawartość YML:

name: build

on:
  push:
  pull_request:
    branches: [ main ]
    paths:
    - '**.cs'
    - '**.csproj'

env:
  DOTNET_VERSION: '6.0.401' # The .NET SDK version to use

jobs:
  build:

    name: build-${{matrix.os}}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macOS-latest]

    steps:
    - uses: actions/checkout@v3
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_VERSION }}

    - name: Install dependencies
      run: dotnet restore
      
    - name: Build
      run: dotnet build --configuration Release --no-restore

W poprzedniej kompozycji przepływu pracy:

  • Definiuje name: build nazwę "kompilacja" będzie wyświetlana w znaczkach stanu przepływu pracy.

    name: build
    
  • Węzeł on oznacza zdarzenia, które wyzwalają przepływ pracy:

    on:
      push:
      pull_request:
        branches: [ main ]
        paths:
        - '**.cs'
        - '**.csproj'
    
    • Wyzwalany, gdy element push lub występuje w main gałęzi, w której wszystkie pliki uległy zmianie kończące się rozszerzeniami plików .cs lub csprojpull_request.
  • Węzeł env definiuje nazwane zmienne środowiskowe (env var).

    env:
      DOTNET_VERSION: '6.0.401' # The .NET SDK version to use
    
    • Zmienna środowiskowa DOTNET_VERSION ma przypisaną wartość '6.0.401'. Później odwołuje się do zmiennej środowiskowej actions/setup-dotnet@v3 w celu określenia dotnet-version akcji usługi GitHub.
  • Węzeł jobs tworzy kroki, które należy wykonać przez przepływ pracy.

    jobs:
      build:
    
        name: build-${{matrix.os}}
        runs-on: ${{ matrix.os }}
        strategy:
          matrix:
            os: [ubuntu-latest, windows-latest, macOS-latest]
    
        steps:
        - uses: actions/checkout@v3
        - name: Setup .NET Core
          uses: actions/setup-dotnet@v3
          with:
            dotnet-version: ${{ env.DOTNET_VERSION }}
    
        - name: Install dependencies
          run: dotnet restore
          
        - name: Build
          run: dotnet build --configuration Release --no-restore
    
    • Istnieje jedno zadanie o nazwie build-<os> , gdzie <os> jest nazwą systemu operacyjnego z strategy/matrix. name Elementy i runs-on są dynamiczne dla każdej wartości w obiekcie matrix/os. Zostanie to uruchomione w najnowszych wersjach systemów Ubuntu, Windows i macOS.

    • Akcja actions/setup-dotnet@v3 usługi GitHub jest wymagana do skonfigurowania zestawu .NET SDK z określoną wersją ze zmiennej środowiskowej DOTNET_VERSION .

    • (Opcjonalnie) W zależności od obciążenia platformy .NET mogą być wymagane dodatkowe kroki. Zostaną one pominięte w tym przykładzie, ale może być konieczne zainstalowanie dodatkowych narzędzi do kompilowania aplikacji.

      • Na przykład podczas kompilowania aplikacji webAssembly platformy ASP.NET Core Blazor z kompilacją AoT (Head-of-Time) należy zainstalować odpowiednie obciążenie przed uruchomieniem operacji przywracania/kompilacji/publikowania.
      - name: Install WASM Tools Workload
        run: dotnet workload install wasm-tools
      

      Aby uzyskać więcej informacji na temat obciążeń platformy .NET, zobacz dotnet workload install.

    • Polecenie dotnet restore jest wywoływane.

    • Polecenie dotnet build jest wywoływane.

W takim przypadku należy traktować plik przepływu pracy jako kompozycję reprezentującą różne kroki tworzenia 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.

Znaczek Tworzenie stanu przepływu pracy

Popularną nomenklaturą repozytoriów GitHub jest posiadanie pliku README.md w katalogu głównym katalogu repozytorium. Podobnie warto zgłosić najnowszy stan dla różnych przepływów pracy. Wszystkie przepływy pracy mogą wygenerować wskaźnik stanu, który jest wizualnie atrakcyjny w pliku README.md . Aby dodać wskaźnik stanu przepływu pracy:

  1. W repozytorium GitHub wybierz opcję nawigacji Akcje .

  2. Wszystkie przepływy pracy repozytorium są wyświetlane po lewej stronie, wybierz żądany przepływ pracy i przycisk wielokropka (...).

    • Przycisk wielokropka (...) rozwija opcje menu dla wybranego przepływu pracy.
  3. Wybierz opcję menu Znaczek Utwórz stan.

    GitHub: Create status badge

  4. Wybierz przycisk Znaczek Stan kopiowania markdown .

    GitHub: Copy status badge Markdown

  5. Wklej znacznik Markdown do pliku README.md , zapisz plik, zatwierdź i wypchnij zmiany.

Aby uzyskać więcej informacji, zobacz Dodawanie wskaźnika stanu przepływu pracy.

Przykładowy wskaźnik stanu przepływu pracy kompilacji

Zaliczone Niepowodzenie Brak stanu
GitHub: build passing badge GitHub: build failing badge GitHub: build no-status badge

Zobacz też

Następne kroki