Exercício – Adicionar os trabalhos Lint e Validar ao fluxo de trabalho

  • 3 minutos

Você conversou com a sua equipe e decidiu automatizar ainda mais suas implantações usando um fluxo de trabalho. Você deseja aumentar sua confiança no que implantará.

Neste exercício, você adicionará trabalhos de validação ao fluxo de trabalho. Em seguida, executará o linter e a validação de comprovação antes de cada implantação.

Durante o processo, você realiza as seguintes tarefas:

  • Atualize o fluxo de trabalho existente para adicionar dois novos trabalhos para usar lint e validar o código Bicep.
  • Executar seu fluxo de trabalho.
  • Corrija todos os problemas detectados pelo fluxo de trabalho.

Adicionar os trabalhos de lint e validação ao fluxo de trabalho

  1. No Visual Studio Code, abra o arquivo workflow.yml na pasta .github/workflows.

  2. Na seção env:, altere o valor da variável AZURE_RESOURCEGROUP_NAME para ToyWebsiteTest:

    env:
  AZURE_RESOURCEGROUP_NAME: ToyWebsiteTest
  ENVIRONMENT_TYPE: Test

  3. Abaixo da linha jobs:, acima do trabalho deploy, adicione um novo trabalho de lint:

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

    Este trabalho define uma etapa para verificar o código e outra que executa o comando az bicep build para executar o arquivo Bicep.

    Dica

    Os arquivos YAML são sensíveis ao recuo. Independentemente de você digitar ou colar esse código, verifique se o recuo está correto. Posteriormente neste exercício, você verá a definição completa do fluxo de trabalho YAML para verificar se o arquivo é correspondente.

  4. Abaixo das linhas que você acabou de adicionar e acima do trabalho de implantação, adicione um trabalho de validação:

    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 trabalho define as etapas para verificar o código, entrar no ambiente do Azure e usar a ação azure/arm-deploy com o modo de implantação Validate.

    Sua definição de fluxo de trabalho agora tem três trabalhos. O primeiro usa o lint em seu arquivo Bicep, o segundo executa uma validação de comprovação e o terceiro realiza a implantação no Azure.

  5. Abaixo da linha runs-on no trabalho deploy, adicione uma instrução needs:

    deploy:
  runs-on: ubuntu-latest
  needs: [lint, validate]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure

    A instrução needs indica que a execução do trabalho de implantação depende da conclusão bem-sucedida dos trabalhos de lint e validação.

    Observe também que tanto os trabalhos de validação quanto os de implantação entram no Azure e todos eles verificam o código do repositório. Essas etapas são necessárias porque cada trabalho usa um novo executor do GitHub.

  6. Salve o arquivo.

Configurar o linter

Por padrão, o linter do Bicep fornece um aviso quando detecta um problema com o arquivo. O GitHub Actions não trata os avisos do linter como problemas que devem interromper o fluxo de trabalho. Para personalizar esse comportamento, você cria um arquivo bicepconfig.json que reconfigura o linter.

  1. Adicione um novo arquivo na pasta deploy e dê a ele o nome bicepconfig.json.

    Captura de tela do Visual Studio Code Explorer, com o novo arquivo mostrado na pasta de implantação.

  2. Copie e cole o seguinte código no arquivo :

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

  3. Salve o arquivo.

Configure o trabalho de implantação para trabalhar com o linter

Quando você usa uma configuração personalizada do linter, o Bicep grava dados de log que o GitHub Actions interpreta como um erro. Para desabilitar esse comportamento, configure a tarefa arm-deploy para ignorar o fluxo de log de erro padrão (stderr).

  1. Abra o arquivo workflow.yml.

  2. Na etapa de teste Implantar site do trabalho deploy, configure a propriedade failOnStdErr como 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 }}

  3. Salve o arquivo.

Verificar e fazer commit a definição do fluxo de trabalho

  1. Verifique se o arquivo workflow.yml é semelhante ao seguinte código:

    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 o seu arquivo tiver uma aparência diferente, atualize-o para que corresponda a este exemplo e, em seguida, salve-o.

  2. Faça commit e efetue push das alterações no repositório Git executando os seguintes comandos no terminal do Visual Studio Code:

    git add .
git commit -m "Add lint and validation jobs"
git push

  3. Esse commit é a primeira vez que você efetuou push desse repositório. Por isso, pode aparecer uma solicitação para entrada.

    No Windows, digite 1 para autenticar usando um navegador da Web e selecione Enter.

    No macOS, selecione Autorizar.

  4. Uma janela do navegador é exibida. Talvez seja necessário entrar no GitHub novamente. Selecione Autorizar.

    Imediatamente após efetuar push, o GitHub Actions inicia uma nova execução do fluxo de trabalho.

Ver a execução do fluxo de trabalho

  1. No navegador, acesse Ações.

    A primeira execução do fluxo de trabalho, Commit Inicial, é mostrada como uma falha. O GitHub executou automaticamente o fluxo de trabalho quando você criou o repositório. Ele falhou porque os segredos não estavam prontos naquele momento. Você pode ignorar essa falha.

  2. Selecione a execução mais recente do fluxo de trabalho.

    Captura de tela do GitHub Actions com o link para o fluxo de trabalho mais recente realçado.

    Observe que a execução do fluxo de trabalho agora mostra os três trabalhos que você definiu no arquivo YAML. Os trabalhos Lint e Validar são executados em paralelo antes do início do trabalho de implantação.

  3. Se o fluxo de trabalho ainda estiver em execução, aguarde até que ele seja concluído. Embora os fluxos de trabalho atualizem a página automaticamente com o status mais recente, é melhor atualizar página de vez em quando.

    Observe que ocorreu uma falha nos trabalhos lint e validar.

    Captura de tela de um fluxo de trabalho executado no GitHub Actions, com falhas relatadas pelos trabalhos Lint e Validar.

  4. Selecione o trabalho de lint para ver os detalhes.

  5. Escolha a etapa Executar linter do Bicep para ver o log do fluxo de trabalho.

    Captura de tela do log de fluxo de trabalho para o trabalho de Lint, com a etapa para executar um linter do Bicep realçada.

    O erro no log de fluxo de trabalho inclui uma mensagem de erro do linter:

    Error no-unused-params: Parameter "storageAccountNameParam" is declared but never used.

    Esta mensagem de erro indica que o linter encontrou uma violação de regra em seu arquivo Bicep.

Corrigir o erro do linter

Agora que você identificou o problema, poderá corrigi-lo no arquivo Bicep.

  1. No Visual Studio Code, abra o arquivo main.bicep na pasta deploy.

  2. Observe que o linter do Bicep também detectou que o parâmetro storageAccountNameParam não foi usado. No Visual Studio Code, uma linha ondulada é exibida sob o parâmetro. Normalmente, a linha seria amarela para indicar um aviso. Mas como você personalizou o arquivo bicepconfig.json, o linter trata o código como um erro e exibe a linha em vermelho.

    param storageAccountNameParam string = uniqueString(resourceGroup().id)

  3. Exclua o parâmetro storageAccountNameParam.

  4. Salve o arquivo.

  5. Faça commit e efetue push das alterações no repositório Git executando os seguintes comandos no terminal do Visual Studio Code:

    git add .
git commit -m "Remove unused parameter"
git push

    Mais uma vez, o GitHub Actions dispara automaticamente uma nova execução do fluxo de trabalho.

Ver novamente a execução do fluxo de trabalho

  1. No navegador, acesse o fluxo de trabalho.

  2. Selecione a execução mais recente.

    Aguarde até que a execução do fluxo de trabalho seja concluída. Embora o GitHub Actions atualize automaticamente a página com o status mais recente, é uma boa ideia atualizá-la ocasionalmente.

  3. Observe que o trabalho Lint foi concluído com sucesso, mas o trabalho Validar ainda apresenta falha.

    Captura de tela da execução do fluxo de trabalho, com o sucesso relatado pelo trabalho Lint e a falha relatada pelo trabalho Validar.

  4. Selecione o trabalho Validar para ver os detalhes.

  5. Escolha a etapa Executar validação de comprovação para ver o log do fluxo de trabalho.

    Captura de tela do log do fluxo de trabalho para o trabalho Validar, com a etapa para executar a validação de comprovação realçada.

    O erro exibido no log do fluxo de trabalho inclui a seguinte mensagem:

    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.

    Esse erro indica que o nome da conta de armazenamento não é válido.

Corrigir o erro de validação

Você encontrou outro problema no arquivo Bicep. Aqui, você corrigirá o problema.

  1. No Visual Studio Code, abra o arquivo main.bicep na pasta deploy.

  2. Examine a definição da variável storageAccountName:

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

    Parece haver um erro de digitação, e a interpolação de cadeia de caracteres não foi configurada corretamente.

  3. Atualize a variável storageAccountName para que ela use a interpolação de cadeia de caracteres corretamente:

    var storageAccountName = 'mystorage${resourceNameSuffix}'

  4. Salve o arquivo.

  5. Faça commit e efetue push das alterações no repositório Git executando os seguintes comandos no terminal do Visual Studio Code:

    git add .
git commit -m "Fix string interpolation"
git push

Ver a execução bem-sucedida do fluxo de trabalho

  1. No navegador, acesse o fluxo de trabalho.

  2. Selecione a execução mais recente.

    Aguarde até que a execução do fluxo de trabalho seja concluída. Embora o GitHub Actions atualize automaticamente a página com o status mais recente, é uma boa ideia atualizá-la ocasionalmente.

  3. Observe que os três trabalhos no fluxo de trabalho foram concluídos com sucesso:

    Captura de tela do fluxo de trabalho executado no GitHub Actions, com os três trabalhos relatando sucesso.

    Alguns avisos são listados no painel Anotações. Todos esses avisos são exibidos por causa da maneira como o Bicep grava as mensagens informativas no log do fluxo de trabalho. Você pode ignorar esses avisos.

Agora você tem um fluxo de trabalho que detecta com êxito erros no código Bicep no início do processo de implantação e que, depois, realiza a implantação no Azure se não há erros.