Ejercicio: Incorporación, aplicación de linting y validación de trabajos en el flujo de trabajo

3 minutos

Ha hablado con el equipo y ha decidido automatizar aún más las implementaciones mediante un flujo de trabajo. Quiere generar más confianza en lo que implementa.

En este ejercicio, agregará trabajos de validación al flujo de trabajo. Después, ejecutará la validación de linter y preparatoria antes de cada implementación.

Durante el proceso, realizará estas tareas:

Actualizar el flujo de trabajo existente para agregar dos nuevos trabajos de linting y validación del código de Bicep.
Ejecución del flujo de trabajo.
Corregir los problemas que detecte el flujo de trabajo.

Incorporación de trabajos de linting y validación al flujo de trabajo

En Visual Studio Code, abra el archivo workflow.yml en la carpeta .github/workflows.
En la sección env:, cambie el valor de la variable AZURE_RESOURCEGROUP_NAME a ToyWebsiteTest:
```
env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test
```
Debajo de la línea jobs:, encima del trabajo deploy, agregue un nuevo trabajo de linting:
```
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file deploy/main.bicep
```
Este trabajo define un paso para extraer el código del repositorio y un paso que ejecuta el comando az bicep build para agregar tareas de linting al archivo de Bicep.

Sugerencia

Los archivos YAML son sensibles a la sangría. Tanto si escribe o pega este código, asegúrese de que la sangría es correcta. Más adelante en este ejercicio, verá la definición de flujo de trabajo de YAML completa para que pueda comprobar que el archivo coincide.

Debajo de las líneas que acaba de agregar y encima del trabajo de implementación, agregue un trabajo de validación:

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

Este trabajo define los pasos para extraer el código del repositorio, iniciar sesión en el entorno de Azure y usar la acción azure/arm-deploy con el modo de implementación Validate.

La definición de flujo de trabajo ahora tiene tres trabajos. El primero agrega tareas de linting al archivo de Bicep, el segundo realiza una validación preparatoria y el tercero realiza la implementación en Azure.

Debajo de la línea runs-on en el trabajo deploy, agregue una instrucción needs:
```
deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
```
La instrucción needs indica que el trabajo de implementación depende de que los trabajos de linting y de validación se completen correctamente antes de que se pueda ejecutar.

Observe también que los trabajos de validación e implementación inician sesión en Azure, y todos los trabajos extraen el código del repositorio. Estos pasos son necesarios porque cada trabajo usa un nuevo ejecutor de GitHub.
Guarde el archivo.

Configuración del linter

De forma predeterminada, el linter de Bicep proporciona una advertencia cuando detecta un problema con el archivo. Acciones de GitHub no tratan las advertencias de linter como problemas que deben detener el flujo de trabajo. Para personalizar este comportamiento, debe crear un archivo bicepconfig.json que vuelva a configurar el linter.

Agregue un archivo nuevo en la carpeta deploy, con el nombre asíbicepconfig.json.

Copie y pegue el siguiente código en el archivo :

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

Guarde el archivo.

Configuración del trabajo de implementación para que funcione con el linter

Cuando se usa una configuración de linter personalizada, Bicep escribe datos de registro que Acciones de GitHub interpreta como un error. Para deshabilitar este comportamiento, se debe configurar la tarea arm-deploy para omitir la secuencia de registro de errores estándar (stderr).

Abra el archivo workflow.yml.

En el paso de prueba Deploy website del trabajo deploy, establezca la propiedad failOnStdErr en 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 }}

Guarde el archivo.

Comprobación y confirmación de la definición de flujo de trabajo

Compruebe que el archivo workflow.yml es similar al código siguiente:

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

Si el archivo tiene un aspecto diferente, actualícelo para que coincida con este ejemplo y guárdelo.

Confirme e inserte los cambios en el repositorio de Git mediante la ejecución de los comandos siguientes en el terminal de Visual Studio Code:
```
git add .
git commit -m "Add lint and validation jobs"
git push
```
Esta confirmación es la primera vez que inserta contenido este repositorio, por lo que es posible que se le pida que inicie sesión.

En Windows, escriba 1 para autenticarse mediante un explorador web y presione Entrar.

En macOS, seleccione Autorizar.
Aparece una ventana del explorador. Puede que tenga que volver a iniciar sesión en GitHub. Seleccione Autorizar.

Inmediatamente después de la inserción, Acciones de GitHub inicia una nueva ejecución de flujo de trabajo.

Visualización de la ejecución del flujo de trabajo

En el explorador, vaya Acciones.

La primera ejecución del flujo de trabajo, con la etiqueta Initial commit (Confirmación inicial), se muestra como un error. GitHub ejecutó automáticamente el flujo de trabajo al crear el repositorio. Se produjo un error porque los secretos no estaban listos en ese momento. Puede omitir este error.
Seleccione la ejecución más reciente del flujo de trabajo.

Observe que la ejecución del flujo de trabajo muestra ahora los tres trabajos definidos en el archivo YAML. Los trabajos lint y validate (validación) se ejecutan en paralelo antes de que se inicie el trabajo deploy (implementación).
Si el flujo de trabajo sigue en ejecución, espere hasta que finalice. Aunque los flujos de trabajo actualizan automáticamente la página con el estado más reciente, es recomendable actualizarla ocasionalmente.

Observe también que se ha producido un error en los trabajos lint y validate.
Seleccione el trabajo lint para ver sus detalles.
Seleccione el paso Run Bicep linter (Ejecutar linter de Bicep) para ver el registro de flujo de trabajo.

El error del registro de flujo de trabajo incluye un mensaje de error linter:
```
Error no-unused-params: Parameter "storageAccountNameParam" is declared but never used.
```
Este mensaje de error indica que el linter ha encontrado una infracción de regla en el archivo de Bicep.

Corrección del error de linter

Ahora que ha identificado el problema, puede corregirlo en el archivo de Bicep.

En Visual Studio Code, abra el archivo main.bicep de la carpeta deploy.
Observe que el linter de Bicep también ha detectado que no se usa el parámetro storageAccountNameParam. En Visual Studio Code, se muestra una línea ondulada bajo el parámetro. Normalmente, la línea sería amarilla para indicar una advertencia. Pero como ha personalizado el archivo bicepconfig.json, el linter trata el código como un error y muestra la línea en rojo.
```
param storageAccountNameParam string = uniqueString(resourceGroup().id)
```
Elimine el parámetro storageAccountNameParam.
Guarde el archivo.
Confirme e inserte los cambios en el repositorio de Git mediante la ejecución de los comandos siguientes en el terminal de Visual Studio Code:
```
git add .
git commit -m "Remove unused parameter"
git push
```
Una vez más, Acciones de GitHub desencadena automáticamente una ejecución nueva del flujo de trabajo.

Visualización de nuevo de la ejecución del flujo de trabajo

En el explorador, vaya al flujo de trabajo.
Seleccione la ejecución más reciente.

Espere hasta que finalice la ejecución del flujo de trabajo. Aunque Acciones de GitHub actualiza automáticamente la página con el estado más reciente, es recomendable actualizarla ocasionalmente.
Observe que el trabajo lint se ha completado correctamente, pero todavía se ha producido un error en el trabajo Validate (Validación).
Seleccione el trabajo Validate (Validación) para ver sus detalles.
Seleccione el paso Run preflight validation (Ejecutar validación preparatoria) para ver el registro de flujo de trabajo.

El error que aparece en el registro del flujo de trabajo incluye el mensaje siguiente:
```
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.
```
Este error indica que el nombre de la cuenta de almacenamiento no es válido.

Corrección del error de validación

Ha encontrado otro problema en el archivo de Bicep. Aquí, corregirá el problema.

En Visual Studio Code, abra el archivo main.bicep de la carpeta deploy.

Mire la definición de la variable storageAccountName:

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

Parece haber un error tipográfico y la interpolación de cadenas no se ha configurado correctamente.

Actualice la variable storageAccountName para que use correctamente la interpolación de cadenas:
```
var storageAccountName = 'mystorage${resourceNameSuffix}'
```
Guarde el archivo.
Confirme e inserte los cambios en el repositorio de Git mediante la ejecución de los comandos siguientes en el terminal de Visual Studio Code:
```
git add .
git commit -m "Fix string interpolation"
git push
```

Visualización de la ejecución correcta del flujo de trabajo

En el explorador, vaya al flujo de trabajo.
Seleccione la ejecución más reciente.

Espere hasta que finalice la ejecución del flujo de trabajo. Aunque Acciones de GitHub actualiza automáticamente la página con el estado más reciente, es recomendable actualizarla ocasionalmente.
Observe que los tres trabajos del flujo de trabajo han finalizado correctamente:

Algunas advertencias se muestran en el panel Annotations (Anotaciones). Estas advertencias aparecen debido a la forma en que Bicep escribe mensajes informativos en el registro de flujo de trabajo. Puede omitir estas advertencias.

Ahora tiene un flujo de trabajo que detecta correctamente errores en el código de Bicep al principio del proceso de implementación y, después, se implementa en Azure si no hay errores.