Use gatilhos para controlar quando o fluxo de trabalho é executado

• 5 minutos

Agora você tem um fluxo de trabalho que implanta seu arquivo Bicep em seu ambiente do Azure. No entanto, sempre que alterar o ficheiro, tem de executar manualmente o fluxo de trabalho. Nesta unidade, você aprenderá como acionar seu fluxo de trabalho para ser executado automaticamente sempre que o código do Bíceps for alterado.

O que é um gatilho de fluxo de trabalho?

Um gatilho de fluxo de trabalho é uma condição que, quando atendida, executa automaticamente seu fluxo de trabalho com base nas regras criadas. Você pode definir gatilhos para executar seu fluxo de trabalho em intervalos agendados. Você também pode definir gatilhos para executar seu fluxo de trabalho sempre que um arquivo no repositório for alterado. Você pode escolher a segunda opção, porque é uma boa ideia executar todos os seus testes e etapas de implantação sempre que alguém alterar seu código.

Se você não usar um gatilho automático, alguém poderá fazer uma alteração em um arquivo Bicep e até mesmo confirmá-lo e enviá-lo por push para o repositório, mas se esquecer de executar o fluxo de trabalho, haverá uma diferença entre as definições de recursos em seu arquivo Bicep e os recursos implantados em seu ambiente do Azure. Suponha que mais alguns commits e pushes sejam feitos, mas não implantados. Se alguém introduzir um erro ou configuração incorreta no arquivo Bicep em uma dessas alterações, pode ser difícil rastrear o erro entre as várias confirmações que são implantadas posteriormente de uma só vez. Depois de um tempo, você não confiará que seu código Bicep realmente representa sua infraestrutura e seu valor será corroído.

Quando você configura seu fluxo de trabalho para ser executado sempre que atualiza seus arquivos, no momento em que as alterações são enviadas por push, o fluxo de trabalho começa a ser executado. Você recebe feedback instantâneo sobre a validade da alteração e pode ter certeza de que seu ambiente de produção está sempre atualizado.

Acionadores de eventos push

Um tipo comum de gatilho é um gatilho de evento push, também chamado de gatilho de integração contínua ou gatilho de CI. Quando você usa um gatilho de evento push, sempre que faz uma alteração em uma ramificação específica, o fluxo de trabalho é executado. Se você confirmar e enviar uma alteração para uma ramificação diferente, o fluxo de trabalho não será acionado e não será executado. É comum usar esse tipo de gatilho contra sua ramificação padrão ou principal , com este código:

on:
  push:
    branches:
      - main

Acionar quando várias ramificações mudam

Você pode configurar gatilhos para executar seu fluxo de trabalho em uma ramificação específica ou em conjuntos de ramificações. Por exemplo, suponha que você crie ramificações de versão que contenham o código que você implantará para uma versão específica do seu projeto. Você pode usar nomes de ramificações como release/v1, release/v2 e assim por diante. Você deseja executar seu fluxo de trabalho sempre que seu código for alterado em uma ramificação que comece com o nome release/. Você pode usar um curinga ** :

on:
  push:
    branches:
      - main
      - 'release/**'

Você também pode excluir ramificações específicas. Suponha que você esteja colaborando com membros da equipe em seu projeto. Seus colegas criam ramificações de recursos para experimentar suas ideias em arquivos Bicep. Todas as ramificações de recursos têm nomes como recurso/adicionar banco de dados, recurso/melhorar o desempenho e assim por diante. Você deseja executar seu fluxo de trabalho automaticamente em todas as ramificações, exceto nas ramificações de recursos criadas por seus colegas. Ao usar a exclude propriedade, você garante que o fluxo de trabalho não seja acionado automaticamente para alterações em ramificações de recursos:

on:
  push:
    branches-ignore:
      - 'feature/**'

on:
  push:
    branches:
      - main
      - 'release/**'
      - '!release/**-alpha'

Filtros de caminho

Às vezes, você tem arquivos em seu repositório que não estão relacionados à sua implantação. Por exemplo, você pode ter uma pasta de implantação em seu repositório que contenha seu código Bicep e uma subpasta docs que contenha seus arquivos de documentação. Você deseja acionar seu fluxo de trabalho quando alguém fizer uma alteração em qualquer um dos arquivos Bicep na pasta de implantação, mas não deseja acionar o fluxo de trabalho se alguém alterar apenas um arquivo de documentação. Para configurar um gatilho para responder a alterações em uma pasta específica no repositório, você pode usar um filtro de caminho:

on:
  push:
    paths:
      - 'deploy/**'
      - '!deploy/docs/**'

Se alguém confirmar uma alteração que atualize apenas um arquivo de documentação, o fluxo de trabalho não será executado. Mas se alguém alterar um arquivo Bicep, ou mesmo se alterar um arquivo Bicep além de um arquivo de documentação, o gatilho executa o fluxo de trabalho.

Agende seu fluxo de trabalho para ser executado automaticamente

Você pode executar seu fluxo de trabalho em um cronograma definido e não em resposta a uma alteração de arquivo. Por exemplo, você pode executar uma versão noturna do seu código Bicep ou implantar automaticamente um ambiente de teste todas as manhãs. Use a palavra-chave e defina a schedule frequência usando uma expressão cron:

on:
  schedule:
    - cron: '0 0 * * *'

O evento schedule sempre executa seu fluxo de trabalho na ramificação padrão do repositório.

Usar vários gatilhos

Você pode combinar gatilhos e agendas, como neste exemplo:

on:
  push:
    branches:
      - main
  schedule:
    - cron: '0 0 * * *'

Quando você cria um gatilho de ramificação e um gatilho agendado no mesmo fluxo de trabalho, o fluxo de trabalho é executado sempre que um arquivo é alterado na ramificação definida no gatilho e na agenda definida. Neste exemplo, o fluxo de trabalho é executado todos os dias à meia-noite UTC e também sempre que uma alteração é enviada por push para a ramificação principal .

Gatilhos Webhook

O GitHub também fornece eventos webhook, que são executados automaticamente quando determinados eventos acontecem em seu repositório. Esses eventos incluem alguém criando uma ramificação, atualizações para seus problemas do GitHub ou alterações para solicitações pull. Geralmente, esses eventos não exigem que o fluxo de trabalho de implantação do Bicep seja executado, mas você pode executar outra automação.

Controlo de simultaneidade

Por padrão, o GitHub Actions permite que várias instâncias do seu fluxo de trabalho sejam executadas simultaneamente. Isso pode acontecer quando você faz várias confirmações em uma ramificação em um curto espaço de tempo ou se uma execução anterior não foi concluída quando sua agenda for acionada em seguida.

Em algumas situações, ter várias execuções simultâneas do seu fluxo de trabalho não é um problema. No entanto, quando você trabalha com fluxos de trabalho de implantação, pode ser um desafio garantir que suas execuções de fluxo de trabalho não substituam seus recursos ou configuração do Azure de maneiras que você não espera.

Para evitar esses problemas, você pode aplicar o controle de simultaneidade. Use a palavra-chave concurrency e especifique uma cadeia de caracteres consistente em todas as execuções do seu fluxo de trabalho. Geralmente é uma cadeia de caracteres codificada, como neste exemplo:

concurrency: MyWorkflow

Em seguida, o GitHub Actions garante que ele aguarde a conclusão de qualquer execução de fluxo de trabalho ativo antes de iniciar uma nova execução.