Übung: Hinzufügen von Linting- und Überprüfungsaufträgen zu Ihrem Workflow

3 Minuten

Sie haben mit Ihrem Team gesprochen und entschieden, dass Sie Ihre Bereitstellungen mithilfe eines Workflows weiter automatisieren werden. Sie möchten mehr Vertrauen in die Bereitstellung schaffen.

In dieser Übung fügen Sie Ihrem Workflow Überprüfungsaufträge hinzu. Anschließend führen Sie das Linting und die Preflightvalidierung vor jeder Bereitstellung aus.

Während des Vorgangs führen Sie die folgenden Aufgaben aus:

Sie aktualisieren Ihren vorhandenen Workflow, um Ihrem Bicep-Code zwei neue Aufträge für das Linting und die Überprüfung hinzuzufügen.
Ausführen Ihres Workflows
Sie beheben alle Probleme, die Ihr Workflow erkennt.

Hinzufügen von Linting- und Überprüfungsaufträgen zu Ihrem Workflow

Öffnen Sie in Visual Studio Code die Datei workflow.yml im Ordner .github/workflows.
Ändern Sie im Abschnitt env: den Wert der Variable AZURE_RESOURCEGROUP_NAME in ToyWebsiteTest:
```
env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test
```
Fügen Sie unterhalb der Zeile jobs: und über dem Auftrag deploy einen neuen Lintingauftrag hinzu:
```
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file deploy/main.bicep
```
Dieser Auftrag definiert einen Schritt zum Auschecken des Codes und einen Schritt, in dem der Befehl az bicep build zum Linten der Bicep-Datei ausgeführt wird.

Tipp

YAML-Dateien berücksichtigen Einzüge. Unabhängig davon, ob Sie diesen Code eingeben oder einfügen, stellen Sie sicher, dass der Einzug korrekt ist. Später in dieser Übung sehen Sie die vollständige YAML-Workflowdefinition, sodass Sie überprüfen können, ob Ihre Datei übereinstimmt.

Fügen Sie unterhalb der soeben hinzugefügten Zeilen und oberhalb des Bereitstellungsauftrags einen Überprüfungsauftrag hinzu:

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

Dieser Auftrag definiert Schritte zum Auschecken des Codes, zum Anmelden bei Ihrer Azure-Umgebung und zum Verwenden der Aktion azure/arm-deploy im Bereitstellungsmodus Validate.

Ihre Workflowdefinition verfügt jetzt über drei Aufträge. Der erste führt ein Linting Ihrer Bicep-Datei durch, der zweite eine Preflightvalidierung und der dritte die Bereitstellung in Azure.

Fügen Sie unterhalb der Zeile runs-on und über dem Auftrag deploy eine needs-Anweisung hinzu:
```
deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
```
Die needs-Anweisung gibt an, dass die Ausführung des Bereitstellungsauftrags davon abhängt, ob die Linting- und Überprüfungsaufträge erfolgreich abgeschlossen wurden.

Beachten Sie auch, dass sich sowohl die Überprüfungs- als auch die Bereitstellungsaufträge bei Azure anmelden und alle Aufträge den Code aus dem Repository auschecken. Diese Schritte sind erforderlich, da jeder Auftrag einen neuen GitHub-Runner verwendet.
Speichern Sie die Datei .

Konfigurieren des Linters

Standardmäßig gibt der Bicep-Linter eine Warnung aus, wenn ein Problem mit Ihrer Datei erkannt wird. GitHub Actions behandelt Linterwarnungen nicht als Probleme, die Ihren Workflow beenden sollten. Erstellen Sie eine Datei bicepconfig.json, die den Linter neu konfiguriert, um dieses Verhalten anzupassen.

Fügen Sie im Ordner deploy eine neue Datei hinzu, und nennen Sie sie bicepconfig.json.

Kopieren Sie den folgenden Code, und fügen Sie ihn in die Datei ein:

{
  "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"
        }
      }
    }
  }
}

Speichern Sie die Datei .

Konfigurieren des Bereitstellungsauftrags für die Verwendung des Linters

Wenn Sie eine benutzerdefinierte Linterkonfiguration verwenden, schreibt Bicep Protokolldaten, die GitHub Actions als Fehler interpretiert. Um dieses Verhalten zu deaktivieren, konfigurieren Sie den Task arm-deploy so, dass der Protokollstream für Standardfehler (stderr) ignoriert wird.

Öffnen Sie die Datei workflow.yml.

Legen Sie im Testschritt Deploy website (Website bereitstellen) des Auftrags deploy die failOnStdErr-Eigenschaft auf false fest:

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 }}

Speichern Sie die Datei .

Überprüfen und Committen Ihrer Workflowdefinition

Überprüfen Sie, ob die Datei workflow.yml wie im folgenden Code aussieht:

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 }}

Wenn Ihre Datei anders aussieht, aktualisieren Sie sie entsprechend diesem Beispiel und speichern Sie sie.

Committen und pushen Sie Ihre Änderungen in Ihr Git-Repository, indem Sie die folgenden Befehle im Visual Studio Code-Terminal ausführen:
```
git add .
git commit -m "Add lint and validation jobs"
git push
```
Dieser Commit ist der erste Push in dieses Repository, daher werden Sie möglicherweise zur Anmeldung aufgefordert.

Geben Sie unter Windows 1 ein, um sich über einen Webbrowser zu authentifizieren, und drücken Sie die EINGABETASTE.

Wählen Sie unter macOS Authorize (Autorisieren) aus.
Ein Browserfenster wird geöffnet. Möglicherweise müssen Sie sich erneut bei GitHub anmelden. Wählen Sie Autorisieren.

Unmittelbar nach dem Pushen startet GitHub Actions eine neue Workflowausführung.

Anzeigen der Workflowausführung

Navigieren Sie in Ihrem Browser zu Actions.

Für die erste Ausführung Ihres Workflows mit der Bezeichnung Initial commit (Erster Commit) wird ein Fehler angezeigt. GitHub hat den Workflow automatisch ausgeführt, als Sie das Repository erstellt haben. Der Fehler ist aufgetreten, da die Geheimnisse zu diesem Zeitpunkt nicht verfügbar waren. Diesen Fehler können Sie ignorieren.
Wählen Sie die letzte Ausführung Ihres Workflows aus.

Beachten Sie, dass die Workflowausführung nun die drei Aufträge enthält, die Sie in der YAML-Datei definiert haben. Die Aufträge lint und validate werden parallel vor dem Start des Auftrags deploy ausgeführt.
Wenn der Workflow noch ausgeführt wird, warten Sie, bis er abgeschlossen ist. Obwohl Workflows die Seite automatisch mit dem aktuellen Status aktualisieren, sollten Sie die Seite gelegentlich selbst aktualisieren.

Wie Sie sehen, sind bei den Aufträgen lint und validate Fehler aufgetreten.
Wählen Sie den Auftrag lint aus, um die zugehörigen Details anzuzeigen.
Wählen Sie den Schritt Run Bicep linter (Bicep-Linter ausführen) aus, um das Workflowprotokoll anzuzeigen.

Der Fehler im Workflowprotokoll enthält eine Linterfehlermeldung:
```
Error no-unused-params: Parameter "storageAccountNameParam" is declared but never used.
```
Diese Fehlermeldung weist darauf hin, dass der Linter einen Regelverstoß in Ihrer Bicep-Datei gefunden hat.

Beheben des Linter-Fehlers

Nachdem Sie das Problem erkannt haben, können Sie es in Ihrer Bicep-Datei beheben.

Öffnen Sie in Visual Studio Code die Datei main.bicep im Ordner Bereitstellen.
Beachten Sie, dass der Bicep-Linter auch erkannt hat, dass der storageAccountNameParam-Parameter nicht verwendet wird. In Visual Studio Code wird unter dem Parameter eine Wellenlinie angezeigt. Normalerweise wäre die Linie für Warnungen gelb. Da Sie die Datei bicepconfig.json jedoch konfiguriert haben, behandelt der Linter den Code als Fehler und erzeugt eine rote Linie.
```
param storageAccountNameParam string = uniqueString(resourceGroup().id)
```
Löschen Sie den storageAccountNameParam-Parameter.
Speichern Sie die Datei .
Committen und pushen Sie Ihre Änderungen in Ihr Git-Repository, indem Sie die folgenden Befehle im Visual Studio Code-Terminal ausführen:
```
git add .
git commit -m "Remove unused parameter"
git push
```
Auch hier löst GitHub Actions automatisch eine neue Ausführung Ihres Workflows aus.

Erneutes Anzeigen der Workflowausführung

Navigieren Sie in Ihrem Browser zu Ihrem Workflow.
Wählen Sie die letzte Ausführung aus.

Warten Sie, bis die Workflowausführung abgeschlossen ist. Obwohl GitHub Actions die Seite automatisch mit dem aktuellen Status aktualisiert, sollten Sie die Seite gelegentlich aktualisieren.
Der Auftrag lint wurde erfolgreich abgeschlossen, doch jetzt ist bei beim Auftrag validate ein Fehler aufgetreten.
Wählen Sie den Auftrag validate aus, um die zugehörigen Details anzuzeigen.
Wählen Sie den Schritt Run preflight validation (Preflightvalidierung ausführen) aus, um das Workflowprotokoll anzuzeigen.

Der im Workflowprotokoll angezeigte Fehler enthält die folgende Meldung:
```
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.
```
Dieser Fehler gibt an, dass der Name des Speicherkontos ungültig ist.

Beheben des Überprüfungsfehlers

Sie haben ein weiteres Problem in der Bicep-Datei gefunden. Hier beheben Sie das Problem.

Öffnen Sie in Visual Studio Code die Datei main.bicep im Ordner deploy.

Sehen Sie sich die Definition der storageAccountName-Variablen an:

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

Es scheint einen Tippfehler zu geben, und die Zeichenfolgeninterpolation wurde nicht ordnungsgemäß konfiguriert.

Aktualisieren Sie die storageAccountName-Variable, um die Zeichenfolgeninterpolation ordnungsgemäß zu verwenden:
```
var storageAccountName = 'mystorage${resourceNameSuffix}'
```
Speichern Sie die Datei .
Committen und pushen Sie Ihre Änderungen in Ihr Git-Repository, indem Sie die folgenden Befehle im Visual Studio Code-Terminal ausführen:
```
git add .
git commit -m "Fix string interpolation"
git push
```

Anzeigen der erfolgreichen Workflowausführung

Navigieren Sie in Ihrem Browser zu Ihrem Workflow.
Wählen Sie die letzte Ausführung aus.

Warten Sie, bis die Workflowausführung abgeschlossen ist. Obwohl GitHub Actions die Seite automatisch mit dem aktuellen Status aktualisiert, sollten Sie die Seite gelegentlich aktualisieren.
Beachten Sie, dass alle drei Aufträge im Workflow erfolgreich abgeschlossen wurden:

Im Bereich Annotations (Anmerkungen) werden einige Warnungen aufgeführt. Diese Warnungen sind darauf zurückzuführen, wie Bicep Informationsmeldungen in das Workflowprotokoll schreibt. Sie können diese Warnungen ignorieren.

Sie verfügen nun über einen Workflow, der Fehler in Ihrem Bicep-Code frühzeitig im Bereitstellungsprozess erkennt und die Bereitstellung in Azure ausführt, wenn keine Fehler auftreten.