Esercizio - Aggiungere il linting e convalidare i processi nel flusso di lavoro

3 minuti

Dopo aver parlato con il team si è deciso di automatizzare ulteriormente le distribuzioni usando un flusso di lavoro. Si vuole creare maggiore attendibilità in ciò che si distribuisce.

In questo esercizio si aggiungeranno i processi di convalida al flusso di lavoro. Prima di ogni distribuzione verranno quindi eseguiti il linter e la convalida preliminare.

Nel corso del processo verranno eseguite le attività seguenti:

Aggiornare il flusso di lavoro esistente per aggiungere due nuovi processi al linting e convalidare il codice Bicep.
Eseguire il flusso di lavoro.
Risolvere eventuali problemi rilevati dal flusso di lavoro.

Aggiungere processi di convalida e linting al flusso di lavoro

In Visual Studio Code aprire il file wokflow.yml nella cartella .github/workflows.
Nella sezione env: modificare il valore della variabile AZURE_RESOURCEGROUP_NAME in ToyWebsiteTest:
```
env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test
```
Sotto la riga jobs: e sopra il processo deploy aggiungere un nuovo processo di linting:
```
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file deploy/main.bicep
```
Questo processo definisce un passaggio per estrarre il codice e un passaggio che esegue il comando az bicep build per eseguire il linting del file Bicep.

Suggerimento

I file YAML sono sensibili al rientro. Se si digita o si incolla questo codice, assicurarsi che il rientro sia corretto. Più avanti in questo esercizio verrà visualizzata la definizione completa del flusso di lavoro YAML in modo da verificare la corrispondenza del file.

Sotto le righe appena aggiunte e sopra il processo di distribuzione, aggiungere un processo di convalida:

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

Questo processo definisce i passaggi per verificare il codice, accedere all'ambiente di Azure e usare l'azione azure/arm-deploy con la modalità di distribuzione Validate.

La definizione del flusso di lavoro ora include tre processi. La prima esegue il linting del file Bicep, la seconda esegue una convalida preliminare e la terza esegue la distribuzione in Azure.

Sotto la riga runs-on del processo deploy, aggiungere un'istruzione needs:
```
deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
```
L'istruzione needs indica che l'esecuzione del processo di distribuzione avviene dopo il corretto completamento dei processi di linting e di convalida.

Si noti anche che i processi di convalida e distribuzione accedono ad Azure e che tutti i processi verificano il codice nel repository. Questi passaggi sono necessari perché ogni processo usa un nuovo strumento di esecuzione di GitHub.
Salvare il file.

Configurare il linter

Per impostazione predefinita, il linter di Bicep genera un avviso quando rileva un problema con il file. GitHub Actions non considera gli avvisi del linter come problemi che comportano l'arresto del flusso di lavoro. Per personalizzare questo comportamento, si crea un file bicepconfig.json che riconfigura il linter.

Aggiungere un nuovo file nella cartella distribuisci e denominarlo bicepconfig.json.

Copiare e incollare il seguente codice nel file:

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

Salvare il file.

Configurare il processo di distribuzione per l'uso con il linter

Quando si usa una configurazione linter personalizzata, Bicep scrive i dati di log interpretati da GitHub Actions come errore. Per disabilitare questo comportamento, configurare l'attività arm-deploy in modo che ignori il flusso di log di errori standard (stderr).

Aprire il file workflow.yml.

Nel passaggio di test Deploy website del processo deploy, impostare la proprietà failOnStdErr su 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 }}

Salvare il file.

Verificare ed eseguire il commit della definizione del flusso di lavoro

Verificare che il file workflow.yml sia simile al codice seguente:

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

Se il file ha un aspetto diverso, aggiornarlo in modo che corrisponda a questo esempio e quindi salvarlo.

Eseguire il commit e il push delle modifiche nel repository Git eseguendo i comandi seguenti nel terminale di Visual Studio Code:
```
git add .
git commit -m "Add lint and validation jobs"
git push
```
È la prima volta che è stato eseguito il push di questo commit in questo repository, quindi potrebbe essere richiesto di eseguire l'accesso.

In Windows digitare 1 per eseguire l'autenticazione usando un Web browser e premere INVIO.

In macOS selezionare Autorizza.
Verrà visualizzata una finestra del browser. Potrebbe essere necessario accedere di nuovo a GitHub. Seleziona Autorizza.

Immediatamente dopo il push, GitHub Actions avvia una nuova esecuzione del flusso di lavoro.

Visualizzare l'esecuzione del flusso di lavoro

Nel browser passare ad Azioni.

La prima esecuzione del flusso di lavoro, denominata Initial commit, viene visualizzata come errore. GitHub ha eseguito automaticamente il flusso di lavoro al momento della creazione del repository. L'operazione non è riuscita perché i segreti non erano pronti in quel momento. È possibile ignorare questo errore.
Selezionare l'esecuzione più recente del flusso di lavoro.

Si noti che l'esecuzione del flusso di lavoro mostra ora i tre processi definiti dall'utente nei file YAML. I processi di linting e di convalida vengono eseguiti in parallelo prima dell'inizio del processo di distribuzione.
Se il flusso di lavoro è ancora in esecuzione, attenderne il completamento. Anche se i flussi di lavoro aggiornano automaticamente la pagina allo stato più recente, è consigliabile aggiornare la pagina di tanto in tanto.

Si noti che i processi di linting e di convalida non sono riusciti.
Selezionare il processo di linting per visualizzarne i dettagli.
Selezionare il passaggio Run Bicep linter per visualizzare il log del flusso di lavoro.

L'errore nel log del flusso di lavoro include un messaggio di errore linter:
```
Error no-unused-params: Parameter "storageAccountNameParam" is declared but never used.
```
Questo messaggio di errore indica che il linter ha rilevato una violazione della regola nel file Bicep.

Correggere l'errore del linter

Dopo aver identificato il problema, è possibile risolverlo nel file Bicep.

In Visual Studio Code aprire il file main.bicep nella cartella distribuisci.
Si noti che il linter di Bicep ha rilevato anche che il parametro storageAccountNameParam non viene usato. In Visual Studio Code, viene visualizzata una riga ondulata sotto il parametro. Normalmente, la linea è gialla per indicare un avviso, ma poiché il file bicepconfig.json è stato personalizzato, il linter considera il codice come errore e mostra una linea rossa.
```
param storageAccountNameParam string = uniqueString(resourceGroup().id)
```
Eliminare il parametro storageAccountNameParam.
Salvare il file.
Eseguire il commit e il push delle modifiche nel repository Git eseguendo i comandi seguenti nel terminale di Visual Studio Code:
```
git add .
git commit -m "Remove unused parameter"
git push
```
Ancora una volta, GitHub Actions attiva automaticamente una nuova esecuzione del flusso di lavoro.

Visualizzare nuovamente l'esecuzione del flusso di lavoro

Nel browser andare al flusso di lavoro.
Selezionare l'esecuzione più recente.

Attendere il completamento dell'esecuzione del flusso di lavoro. Anche se GitHub Actions aggiorna automaticamente la pagina allo stato più recente, è consigliabile aggiornare la pagina di tanto in tanto.
Si noti che il processo di linting è stato completato correttamente, ma il processo di convalida continua a non riuscire.
Selezionare il processo di convalida per visualizzarne i dettagli.
Selezionare il passaggio Run preflight validation per visualizzare il log del flusso di lavoro.

L'errore visualizzato nel log del flusso di lavoro include il messaggio seguente:
```
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.
```
Questo errore indica che il nome dell'account di archiviazione non è valido.

Correggere l'errore di convalida

È stato rilevato un altro problema nel file Bicep. Qui è possibile correggere il problema.

In Visual Studio Code aprire il file main.bicep nella cartella distribuisci.

Esaminare la definizione della variabile storageAccountName:

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

Sembra che ci sia un errore di digitazione e l'interpolazione di stringhe non è stata configurata correttamente.

Aggiornare la variabile storageAccountName per usare correttamente l'interpolazione di stringhe:
```
var storageAccountName = 'mystorage${resourceNameSuffix}'
```
Salvare il file.
Eseguire il commit e il push delle modifiche nel repository Git eseguendo i comandi seguenti nel terminale di Visual Studio Code:
```
git add .
git commit -m "Fix string interpolation"
git push
```

Visualizzare il flusso di lavoro eseguito correttamente

Nel browser andare al flusso di lavoro.
Selezionare l'esecuzione più recente.

Attendere il completamento dell'esecuzione del flusso di lavoro. Anche se GitHub Actions aggiorna automaticamente la pagina allo stato più recente, è consigliabile aggiornare la pagina di tanto in tanto.
Si noti che tutti e tre i processi nel flusso di lavoro sono stati completati correttamente:

Alcuni avvisi sono elencati nel pannello Annotazioni. Questi avvisi sono dovuti al modo in cui Bicep scrive i messaggi informativi nel log del flusso di lavoro. È possibile ignorare questi avvisi.

È ora disponibile un flusso di lavoro che rileva correttamente gli errori nel codice Bicep all'inizio del processo di distribuzione e quindi esegue la distribuzione in Azure se non sono presenti errori.