Automatizando Fluxos de Trabalho com GitHub Actions

Desvendando o Poder dos GitHub Actions

Olá, sou Jackson, Engenheiro de Software Sênior e Arquiteto de Soluções na AITY. Na nossa série contínua sobre GitHub para Iniciantes, é um prazer mergulhar em um recurso muito popular: GitHub Actions. Ao final deste artigo, você saberá como utilizar esta ferramenta e terá criado seu primeiro fluxo de trabalho automatizado.

GitHub Actions é uma plataforma de Continuous Integration/Continuous Delivery (CI/CD) e automação integrada diretamente ao GitHub. Frequentemente chamados de "fluxos de trabalho de ação" ou simplesmente "fluxos de trabalho", eles permitem automatizar tarefas repetitivas e processos de implantação utilizando arquivos YAML armazenados em seu repositório. Você pode usar GitHub Actions para diversas finalidades, como:

• Executar verificações de vulnerabilidade
• Rodar testes
• Criar releases
• Enviar lembretes à equipe sobre atualizações importantes

Os fluxos de trabalho de ação são acionados por eventos do GitHub, como pushes, pull requests ou agendamentos, e são executados em um ambiente virtual.

Como os Fluxos de Trabalho Funcionam

Para entender a fundo o funcionamento dos fluxos de trabalho, é essencial definirmos alguns termos cruciais:

• Evento: Uma atividade específica que aciona um fluxo de trabalho (ex: push de código, abertura de um pull request, criação de uma issue, etc.).
• Hosted runners: Uma máquina virtual que executa jobs em um fluxo de trabalho. O GitHub fornece runners hospedados, ou você pode configurar seus próprios runners auto-hospedados.
• Jobs: Um conjunto de steps executados dentro do mesmo runner. Cada step é um comando de shell ou uma ação pré-construída do GitHub Marketplace.

Os fluxos de trabalho são acionados por eventos em um repositório, como um pull request, a fusão de uma branch ou a abertura de uma issue. Ao criar o fluxo de trabalho, você define qual será o evento acionador.

Quando esse evento é disparado e aciona o fluxo de trabalho, o GitHub inicia um ou mais jobs que são executados em um runner. O GitHub então segue os steps programados no fluxo de trabalho até o fim, tudo isso de forma autônoma, sem necessidade de interação humana. É assim que um fluxo de trabalho do GitHub Actions opera.

Construindo um Fluxo de Trabalho

Uma das melhores maneiras de aprender é praticando. Vamos criar um fluxo de trabalho simples que rotulará automaticamente novas issues criadas em nosso repositório.

Os GitHub Actions utilizam a sintaxe YAML para definir fluxos de trabalho. Cada fluxo de trabalho é armazenado em um arquivo .yml dentro de um diretório especial .github\workflows no seu repositório. Ao criar esses arquivos, utilize nomes descritivos que indiquem sua função, como build-and-test.yml ou security-scanner.yml.

Para o nosso exemplo de rotulagem de issues, criaremos um novo arquivo chamado label-new-issue.yml dentro do diretório .github\workflows.

Primeiramente, definimos o nome do nosso fluxo de trabalho, que descreve sua função:

name: Label New Issues

Em seguida, precisamos decidir o que acionará este fluxo de trabalho. O GitHub oferece inúmeras opções de gatilho. Para o nosso caso, queremos que o fluxo de trabalho seja acionado sempre que alguém abrir uma issue. Adicionamos o seguinte código ao arquivo YAML:

on:
  issues:
    types: [opened]

Agora chegamos à seção mais importante: jobs, onde o trabalho real acontece.

• Definição do Job: Damos um título ao nosso job (ex: label-issues) e escolhemos o tipo de máquina (runner) onde ele será executado (ex: ubuntu-latest). O GitHub oferece runners hospedados com diferentes versões de Ubuntu, Windows e macOS.
• Permissões: É necessário adicionar permissões para que a ação possa ler o conteúdo do repositório e adicionar o rótulo. A palavra-chave permissions garante que todas as ações e comandos run dentro desse job obtenham os direitos de acesso especificados.
• Steps: Os steps são as unidades de trabalho. Dentro de um step, você pode usar:
  • uses: Para puxar uma ação pré-construída do GitHub Marketplace. Estas são ações reutilizáveis de código aberto que simplificam tarefas comuns, como checking out seu código ou configurar NodeJS.
  • run: Para executar um comando ou script de shell. Pode ser uma única linha ou um script que se estende por várias linhas.
• Variáveis de Ambiente (env): Aqui definimos variáveis de ambiente. Por exemplo, se usarmos o GitHub CLI em um comando run, precisamos fornecer um token de acesso para a ação. O GitHub gera automaticamente um token temporário (GITHUB_TOKEN) que pode ser usado. Também são necessárias variáveis para identificar a issue e o rótulo a ser adicionado, sendo que o rótulo deve já existir no repositório.

Parabéns! Você concluiu com sucesso a autoria do seu primeiro fluxo de trabalho!

Testando e Revisando Fluxos de Trabalho

Após criar o fluxo de trabalho, é hora de testá-lo. Primeiro, precisamos enviar essas alterações para o repositório e mesclá-las na branch principal. Uma vez na branch principal, podemos vê-lo em ação.

Para testar: 1. Navegue até o repositório no seu navegador e selecione a aba Issues. 2. No canto superior direito, selecione o botão verde New issue. 3. Forneça um título e uma descrição indicando que você está testando o fluxo de trabalho e clique em Create.

O GitHub criará a issue e automaticamente o levará à página que mostra o histórico da issue. Se tudo estiver funcionando corretamente, você verá o rótulo triage adicionado em segundos após a criação da issue. Isso demonstra a conveniência de ter ações que lidam automaticamente com tarefas com base em gatilhos específicos.

Para revisar os fluxos de trabalho atuais: 1. Selecione a aba Actions na parte superior da janela. Você verá todos os fluxos de trabalho listados em uma coluna à esquerda. 2. Selecione Label New Issues para filtrar a visualização e mostrar apenas as vezes que este fluxo de trabalho foi executado. 3. Selecione a execução mais recente do fluxo de trabalho (que deve ser para a issue de teste que você criou). Isso o levará a uma página de detalhes onde você pode ver mais informações sobre essa instância específica do fluxo de trabalho. 4. Selecione label-issues na janela principal. Agora você pode ver todos os steps executados para completar o fluxo de trabalho. Isso é muito útil para depuração, caso um de seus fluxos de trabalho não esteja funcionando como esperado. 5. Você pode reexecutar este fluxo de trabalho clicando no botão Re-run all jobs no canto superior direito.

Caso precise pausar um fluxo de trabalho, pode fazê-lo a partir da aba Actions. Selecione Label New Issues novamente na coluna esquerda. Clique nos três pontos (...) ao lado da caixa de pesquisa. Uma das opções é Disable workflow. Ao selecioná-la, o fluxo de trabalho será interrompido, mas continuará existindo no repositório para que possa ser reativado posteriormente.

A aba Actions é o local central para visualizar e gerenciar todos os seus fluxos de trabalho, verificar implantações, runners, métricas, desempenho e caches. Você também pode visualizar e editar seus arquivos de fluxo de trabalho diretamente nesta aba.

Impacto Prático e Próximos Passos

Os GitHub Actions são muito mais do que apenas rotular issues. Eles podem ser utilizados para uma vasta gama de automações, como publicar pacotes, cumprimentar novos contribuidores, construir e testar seu código, e até mesmo executar verificações de segurança.

A capacidade de automatizar tarefas repetitivas e processos de CI/CD diretamente no seu repositório GitHub significa uma melhoria significativa na eficiência operacional e na consistência das suas entregas. Como Engenheiro de Software Sênior e Arquiteto de Soluções, vejo o GitHub Actions como uma ferramenta indispensável para otimizar fluxos de trabalho, reduzir erros manuais e acelerar o ciclo de vida do desenvolvimento de software. Encorajo você a continuar explorando as documentações do GitHub Actions e a experimentar a criação de seus próprios fluxos de trabalho para descobrir todo o seu potencial.