Ćwiczenie — dodawanie lint i weryfikowanie zadań do przepływu pracy

3 min

Rozmawiałeś z zespołem i zdecydowałeś się jeszcze bardziej zautomatyzować wdrożenia przy użyciu przepływu pracy. Chcesz budować większą pewność co do wdrażanych rozwiązań.

W tym ćwiczeniu dodasz zadania weryfikacji do przepływu pracy. Następnie uruchomisz linter i walidację wstępną przed każdym wdrożeniem.

Podczas tego procesu wykonujesz następujące zadania:

Zaktualizuj istniejący przepływ pracy, aby dodać dwa nowe zadania do lint i zweryfikować kod Bicep.
Uruchom przepływ pracy.
Rozwiąż wszelkie problemy wykryte przez przepływ pracy.

Dodawanie zadań lint i walidacji do przepływu pracy

W programie Visual Studio Code otwórz plik workflow.yml w folderze .github/workflows .
env: W sekcji zmień wartość zmiennej AZURE_RESOURCEGROUP_NAME na ToyWebsiteTest:
```
env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test
```
Pod wierszem jobs:deploy powyżej zadania dodaj nowe zadanie lint:
```
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file deploy/main.bicep
```
To zadanie definiuje krok w celu wyewidencjonowania kodu i kroku, który uruchamia az bicep build polecenie w celu lint pliku Bicep.

Napiwek

Pliki YAML są wrażliwe na wcięcia. Bez względu na to, czy wpiszesz, czy wklejasz ten kod, upewnij się, że wcięcie jest poprawne. W dalszej części tego ćwiczenia zobaczysz kompletną definicję przepływu pracy YAML, aby sprawdzić, czy plik jest zgodny.

Poniżej dodanych wierszy i powyżej zadania wdrażania dodaj zadanie weryfikacji:

validate:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    name: Run preflight validation
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
      deploymentMode: Validate

To zadanie definiuje kroki sprawdzania kodu, logowania się do środowiska platformy Azure i używania azure/arm-deploy akcji w trybie Validate wdrażania.

Definicja przepływu pracy zawiera teraz trzy zadania. Pierwsze lints pliku Bicep, drugi wykonuje walidację wstępną, a trzeci wykonuje wdrożenie na platformie Azure.

runs-on Poniżej wiersza zadania deploy dodaj instrukcjęneeds:
```
deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
```
Instrukcja needs wskazuje, że zadanie wdrażania zależy od lint i walidacji zadań ukończonych pomyślnie przed jego uruchomieniem.

Zwróć również uwagę, że zarówno zadania weryfikacji, jak i wdrażania są logowane na platformie Azure, a wszystkie zadania wyewidencjonować kod z repozytorium. Te kroki są niezbędne, ponieważ każde zadanie używa nowego modułu uruchamiającego usługę GitHub.
Zapisz plik.

Konfigurowanie lintera

Domyślnie linter Bicep udostępnia ostrzeżenie, gdy wykryje problem z plikiem. Funkcja GitHub Actions nie traktuje ostrzeżeń linter jako problemów, które powinny zatrzymać przepływ pracy. Aby dostosować to zachowanie, należy utworzyć plik bicepconfig.json , który ponownie konfiguruje linter.

Dodaj nowy plik w folderze deploy i nadaj mu nazwę bicepconfig.json.

Skopiuj i wklej następujący kod do pliku:

{
  "analyzers": {
    "core": {
      "enabled": true,
      "verbose": true,
      "rules": {
        "adminusername-should-not-be-literal": {
          "level": "error"
        },
        "max-outputs": {
          "level": "error"
        },
        "max-params": {
          "level": "error"
        },
        "max-resources": {
          "level": "error"
        },
        "max-variables": {
          "level": "error"
        },
        "no-hardcoded-env-urls": {
          "level": "error"
        },
        "no-unnecessary-dependson": {
          "level": "error"
        },
        "no-unused-params": {
          "level": "error"
        },
        "no-unused-vars": {
          "level": "error"
        },
        "outputs-should-not-contain-secrets": {
          "level": "error"
        },
        "prefer-interpolation": {
          "level": "error"
        },
        "secure-parameter-default": {
          "level": "error"
        },
        "simplify-interpolation": {
          "level": "error"
        },
        "protect-commandtoexecute-secrets": {
          "level": "error"
        },
        "use-stable-vm-image": {
          "level": "error"
        }
      }
    }
  }
}

Zapisz plik.

Konfigurowanie zadania wdrażania w celu pracy z linterem

W przypadku korzystania z niestandardowej konfiguracji linter Bicep zapisuje dane dziennika, które funkcja GitHub Actions interpretuje jako błąd. Aby wyłączyć to zachowanie, należy skonfigurować arm-deploy zadanie tak, aby ignorowało standardowy strumień dziennika błędów (stderr).

Otwórz plik workflow.yml.

deploy W kroku Testuj witrynę internetową w zadaniu ustaw failOnStdErr właściwość na :false

deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    name: Deploy website
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Zapisz plik.

Weryfikowanie i zatwierdzanie definicji przepływu pracy

Sprawdź, czy plik workflow.yml wygląda następująco:

name: deploy-toy-website-test
concurrency: toy-company

on:
  push:
    branches:
      - main

permissions:
  id-token: write
  contents: read

env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file deploy/main.bicep

  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      name: Sign in to Azure
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      name: Run preflight validation
      with:
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
        deploymentMode: Validate

  deploy:
    runs-on: ubuntu-latest
    needs: [lint, validate]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      name: Sign in to Azure
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      name: Deploy website
      with:
        failOnStdErr: false
        deploymentName: ${{ github.run_number }}
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Jeśli plik wygląda inaczej, zaktualizuj go, aby był zgodny z tym przykładem, a następnie zapisz go.

Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Add lint and validation jobs"
git push
```
To zatwierdzenie jest pierwszym wypchnięciem do tego repozytorium, więc może zostać wyświetlony monit o zalogowanie się.

W systemie Windows wpisz 1 , aby uwierzytelnić się przy użyciu przeglądarki internetowej, a następnie wybierz Enter.

W systemie macOS wybierz pozycję Autoryzuj.
Pojawi się okno przeglądarki. Może być konieczne ponowne zalogowanie się do usługi GitHub. Wybierz pozycję Autoryzuj.

Natychmiast po wypchnięciu funkcja GitHub Actions uruchamia nowy przebieg przepływu pracy.

Wyświetlanie przebiegu przepływu pracy

W przeglądarce przejdź do pozycji Akcje.

Pierwszy przebieg przepływu pracy z etykietą Zatwierdzenie początkowe jest wyświetlany jako błąd. Usługa GitHub automatycznie uruchamiała przepływ pracy podczas tworzenia repozytorium. Nie powiodło się, ponieważ wpisy tajne nie były w tym czasie gotowe. Możesz zignorować ten błąd.
Wybierz najnowszy przebieg przepływu pracy.

Zwróć uwagę, że uruchomienie przepływu pracy pokazuje teraz trzy zadania zdefiniowane w pliku YAML. Lint i walidacja zadań są uruchamiane równolegle przed rozpoczęciem zadania wdrażania.
Jeśli przepływ pracy jest nadal uruchomiony, zaczekaj na jego zakończenie. Mimo że przepływy pracy automatycznie aktualizują stronę przy użyciu najnowszego stanu, warto od czasu do czasu odświeżyć stronę.

Zwróć uwagę, że lint i walidacja zadań nie powiodły się.
Wybierz zadanie lint, aby wyświetlić jego szczegóły.
Wybierz krok Uruchom linter Bicep, aby wyświetlić dziennik przepływu pracy.

Błąd w dzienniku przepływu pracy zawiera komunikat o błędzie linter:
```
Error no-unused-params: Parameter "storageAccountNameParam" is declared but never used.
```
Ten komunikat o błędzie wskazuje, że linter odnalazł naruszenie reguły w pliku Bicep.

Naprawianie błędu linter

Po zidentyfikowaniu problemu możesz go rozwiązać w pliku Bicep.

W programie Visual Studio Code otwórz plik main.bicep w folderze deploy .
Zwróć uwagę, że linter Bicep również wykrył, że storageAccountNameParam parametr nie jest używany. W programie Visual Studio Code w obszarze parametru jest wyświetlany wiersz z falochła. Zwykle linia będzie żółta, aby wskazać ostrzeżenie. Ale ponieważ dostosowano plik bicepconfig.json , linter traktuje kod jako błąd i wyświetla wiersz na czerwono.
```
param storageAccountNameParam string = uniqueString(resourceGroup().id)
```
storageAccountNameParam Usuń parametr .
Zapisz plik.
Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Remove unused parameter"
git push
```
Po raz kolejny funkcja GitHub Actions automatycznie wyzwala nowy przebieg przepływu pracy.

Ponowne wyświetlanie przebiegu przepływu pracy

W przeglądarce przejdź do przepływu pracy.
Wybierz najnowszy przebieg.

Poczekaj na zakończenie przebiegu przepływu pracy. Chociaż funkcja GitHub Actions automatycznie aktualizuje stronę o najnowszym stanie, warto odświeżyć stronę od czasu do czasu.
Zwróć uwagę, że zadanie lint zakończyło się pomyślnie, ale zadanie sprawdzania poprawności nadal kończy się niepowodzeniem.
Wybierz zadanie weryfikacji, aby wyświetlić jego szczegóły.
Wybierz krok Uruchom weryfikację wstępną, aby wyświetlić dziennik przepływu pracy.

Błąd wyświetlany w dzienniku przepływu pracy zawiera następujący komunikat:
```
mystorageresourceNameSuffix is not a valid storage account name. Storage account name must be between 3 and 24 characters in length and use numbers and lower-case letters only.
```
Ten błąd wskazuje, że nazwa konta magazynu jest nieprawidłowa.

Naprawianie błędu sprawdzania poprawności

W pliku Bicep znaleziono inny problem. W tym miejscu rozwiążesz problem.

W programie Visual Studio Code otwórz plik main.bicep w folderze deploy .

Przyjrzyj się definicji zmiennej storageAccountName :

var appServiceAppName = 'toy-website-${resourceNameSuffix}'
var appServicePlanName = 'toy-website'
var logAnalyticsWorkspaceName = 'workspace-${resourceNameSuffix}'
var applicationInsightsName = 'toywebsite'
var storageAccountName = 'mystorageresourceNameSuffix'

Wydaje się, że jest literówka, a interpolacja ciągów nie jest poprawnie skonfigurowana.

Zaktualizuj zmienną, storageAccountName aby prawidłowo używała interpolacji ciągów:
```
var storageAccountName = 'mystorage${resourceNameSuffix}'
```
Zapisz plik.
Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Fix string interpolation"
git push
```

Wyświetlanie pomyślnego przebiegu przepływu pracy

W przeglądarce przejdź do przepływu pracy.
Wybierz najnowszy przebieg.

Poczekaj na zakończenie przebiegu przepływu pracy. Chociaż funkcja GitHub Actions automatycznie aktualizuje stronę o najnowszym stanie, warto odświeżyć stronę od czasu do czasu.
Zwróć uwagę, że wszystkie trzy zadania w przepływie pracy zakończyły się pomyślnie:

Niektóre ostrzeżenia są wyświetlane w panelu Adnotacje . Te ostrzeżenia są wyświetlane ze względu na sposób, w jaki Bicep zapisuje komunikaty informacyjne w dzienniku przepływu pracy. Możesz zignorować te ostrzeżenia.

Masz teraz przepływ pracy, który pomyślnie wykrywa błędy w kodzie Bicep na wczesnym etapie procesu wdrażania, a następnie wdraża na platformie Azure, jeśli nie ma żadnych błędów.