Usar gatilhos para controlar quando o fluxo de trabalho é executado
Agora você tem um fluxo de trabalho que implanta o arquivo Bicep em seu ambiente do Azure. No entanto, sempre que alterar os arquivos, você deverá executar manualmente o seu fluxo de trabalho. Nesta unidade, você aprenderá a disparar seu fluxo de trabalho para executar automaticamente sempre que o código Bicep for atualizado.
Observação
Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você praticará o que aprendeu aqui em breve.
O que é um gatilho de fluxo de trabalho?
Um gatilho de fluxo de trabalho é uma condição que, quando atendida, executa automaticamente o fluxo de trabalho com base nas regras que você cria. Você pode definir gatilhos para executar seu fluxo de trabalho em intervalos agendados. Você também pode definir gatilhos para executar o seu fluxo de trabalho sempre que um arquivo do seu repositório mudar. Convém escolher a segunda opção, pois o ideal é executar todos os testes e as etapas de implantação sempre que alguém altera o 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 efetuá-lo por push para o repositório. Mas se esquecerem de executar o fluxo de trabalho, haverá uma diferença entre as definições de recurso no arquivo Bicep e os recursos implantados em seu ambiente do Azure. Suponha que mais algumas confirmações e envios por push sejam feitos, mas não implantados. Se alguém apresentar um erro ou uma configuração incorreta no arquivo Bicep em uma dessas alterações, poderá ser difícil rastrear o erro entre as várias confirmações implantadas posteriormente ao mesmo tempo. Após algum tempo, você não confiará que seu código Bicep realmente representa sua infraestrutura e seu ele não terá mais valor.
Quando você configura seu fluxo de trabalho para ser executado sempre que atualiza seus arquivos, no momento em que suas alterações são enviadas por push, o fluxo de trabalho começa a ser executado. Você recebe comentários instantâneos sobre a validade da alteração e pode ter certeza de que seu ambiente de produção está sempre atualizado.
Gatilhos de eventos de push
Um tipo de gatilho comum é um gatilho de evento de push, também conhecido como gatilho de integração contínua ou gatilho de CI. Quando você usa um gatilho de evento de push, sempre que você faz uma alteração em uma ramificação específica, o fluxo de trabalho é executado. Se você confirmar e efetuar push de uma alteração para uma ramificação diferente, o fluxo de trabalho não será disparado e não será executado. É comum usar esse tipo de gatilho em relação à sua ramificação main com este código:
on:
push:
branches:
- main
Disparar quando vários branches mudarem
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 branches de versão que contenham o código que vai 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 o fluxo de trabalho sempre que o código mudar em uma ramificação cujo nome comece com release/. Você pode usar um caractere curinga **:
on:
push:
branches:
- main
- 'release/**'
Você também pode excluir ramificações específicas. Digamos que você esteja colaborando com membros da equipe em seu projeto. Seus colegas criam branches de recursos para experimentar suas ideias em arquivos Bicep. Todas essas ramificações de recursos têm nomes como feature/add-database, feature/improve-performance e assim por diante. Você deseja executar o seu fluxo de trabalho automaticamente em todas as ramificações, exceto nas ramificações de recursos que seus colegas criaram. Usando a propriedade exclude, você faz com que o fluxo de trabalho não seja disparado automaticamente para alterações em ramificações de recursos:
on:
push:
branches-ignore:
- 'feature/**'
Observação
Você pode excluir determinadas ramificações usando o caractere !. Suponha que você queira disparar seu fluxo de trabalho para a ramificação main e para todas as ramificações de versões, exceto para as versões alfa. Você pode usar o caractere ! para expressar isso:
on:
push:
branches:
- main
- 'release/**'
- '!release/**-alpha'
Você não pode usar branches e branches-ignore juntos em um gatilho, portanto, o caractere ! fornece flexibilidade para controlar o comportamento do gatilho.
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 deploy em seu repositório contendo o código do Bicep e uma subpasta documents separada contendo os arquivos de documentação. Você deseja disparar seu fluxo de trabalho quando alguém fizer uma alteração em um dos arquivos Bicep na pasta deploy, mas não quer disparar 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 do seu 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 do Bicep ou mesmo se uma pessoa alterar um arquivo do Bicep adicionalmente a um arquivo de documentação, o gatilho executará o fluxo de trabalho.
Observação
Você também pode usar paths-ignore, que funciona de maneira semelhante à palavra-chave branches-ignore. No entanto, você não pode usar paths e paths-ignore no mesmo gatilho.
Agendar seu fluxo de trabalho para ser executado automaticamente
Você pode executar o fluxo de trabalho em uma agenda definida e não em resposta a uma alteração de arquivo. Por exemplo, você pode executar uma versão noturna do código Bicep ou implantar automaticamente um ambiente de teste todas as manhãs. Use a palavra-chave schedule e defina a frequência usando uma expressão cron:
on:
schedule:
- cron: '0 0 * * *'
Observação
Uma expressão cron é uma sequência de caracteres especialmente formatada que especifica com que frequência algo deve acontecer. Neste exemplo, 0 0 * * * significa executar todos os dias à meia-noite UTC.
Em um arquivo YAML, você precisa adicionar aspas antes e depois de cadeias de caracteres que contenham o caractere *, como expressões cron.
O evento de agenda sempre executa o fluxo de trabalho na ramificação padrão do repositório.
Usar vários gatilhos
Você pode combinar gatilhos e agendamentos, 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 main.
Dica
Uma boa prática é definir gatilhos para cada fluxo de trabalho. Se você não definir gatilhos, por padrão, o fluxo de trabalho será executado automaticamente sempre que qualquer arquivo for alterado em qualquer ramificação, o que geralmente não é o desejável.
Gatilhos de Webhook
O GitHub também fornece eventos de webhook, que são executados automaticamente quando determinados eventos ocorrem em seu repositório. Esses eventos incluem quando alguém cria uma ramificação, atualizações para problemas do GitHub ou alterações nas solicitações de pull. Em geral, esses eventos não exigem que o fluxo de trabalho de implantação do Bicep seja executado, mas você pode executar outra automação.
Controle de simultaneidade
Por padrão, o GitHub Actions permite que várias instâncias do fluxo de trabalho sejam executadas simultaneamente. Isso poderá acontecer quando você fizer várias confirmações em um branch em um curto período de tempo ou se uma execução anterior não tiver sido concluída quando o próximo gatilho estiver agendado para ser disparado.
Em algumas situações, ter várias execuções simultâneas do fluxo de trabalho não é um problema. Mas quando você trabalha com fluxos de trabalho de implantação, pode ser desafiador garantir que as execuções de fluxo de trabalho não estejam substituindo os recursos ou a configuração do Azure de maneiras que você não esperava.
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 fluxo de trabalho. Geralmente, é uma cadeia de caracteres codificada, como neste exemplo:
concurrency: MyWorkflow
O GitHub Actions espera todas as execuções de fluxos de trabalho ativas serem concluídas antes de iniciar uma nova execução.