Entendendo o GitHub Actions
Published Mar 21 2022 02:16 PM 2,074 Views
Microsoft

O GitHub Actions é uma plataforma para automatizar workflows de desenvolvimento de software, ou seja, ele serve não só para implementar CI/CD, mas também para simplificar outros inúmeros processos que existem dentro do ciclo de vida do desenvolvimento de software. 

Neste artigo vamos entender um pouco sobre cada componente e noções básicas para criar o primeiro workflow.

 

Como funciona o Github Actions?

 

O GitHub Actions é orientado por eventos, isso quer dizer que os workflows podem ser acionados a partir de eventos específicos que ocorrem no GitHub. Então é possível, por exemplo, executar um workflow quando alguém fizer um push de um commit para o repositório, ou então quando for criado um issue ou um pull request.

 

A configuração de eventos que acionam o workflow é feita utilizando o parâmetro onAqui temos um exemplo de um workflow configurado para ser acionado através do push de um commit:

 

 

 

 

# .github/workflows/build.yml
name: Node CI
on: [push]

 

 

 

 

Também é possível configurar os workflows para que sejam acionados manualmente, por eventos de webhook ou então por agendamento usando o formato Cron, para entender mais sobre a sintaxe você pode acessar https://pubs.opengroup.org.

 

Segue um exemplo de workflow configurado para ser disparado por agendamento:

 

 

 

 

# .github/workflows/weekly-radar.yml
name: Weekly Radar
on:
  schedule:
  - cron: 0 12 * * 1

 

 

 

 

Aqui você pode encontrar todos os eventos que podem disparar o workflow: https://docs.github.com/pt/actions/learn-github-actions/events-that-trigger-workflows

 

Workflows - Fluxos de trabalho

Os workflows, também conhecidos como fluxos de trabalho, são processos automatizados que adicionamos ao nosso repositório para executar um ou mais trabalhos (jobs). Um repositório pode ter vários workflows e cada um deles podem executar processos diferentes.

Os Workflows são definidos em arquivos YAML, e ficam dentro de uma pasta chamada .github/workflows no repositório.

LumaRodrigues_0-1643316842999.png

 

Jobs - Trabalhos

Os Jobs nada mais são que conjuntos de etapas (steps) que são realizados no mesmo executor (runner).

LumaRodrigues_4-1641579384032.png

 

Por padrão um workflow com vários jobs irá executar esses jobs em paralelo, mas também podemos configurar em nosso workflow para executar os jobs sequencialmente utilizando o parâmetro needs.

 

Steps - Etapas

Os steps são tarefas individuais que podem executar um ou mais comandos dentro de um job. Os steps podem ser Actions ou comandos shell. 

Abaixo podemos ver um exemplo de um step executando uma Action para fazer a instalação da versão do Node.js, e outro step rodando os comandos npm install, build e test.

 

 

 

 

  steps:
  - uses: actions/checkout@v1
# Exemplo de step usando Action
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v1
    with:
     node-version: ${{ matrix.node-version }}
# Exemplo de step usando comando shell 
  - name: npm install, build, and test
    run: |
     npm ci
     npm run build --if-present
     npm test
    env:
     CI: true

 

 

 

 

Actions - Ações

As Actions são comandos independentes, e geralmente executam alguma tarefa que é realizada repetidas vezes nos arquivos de workflow. As Actions foram feitas para serem reutilizáveis, então é possível utilizá-las em vários workflows. Dessa forma, ela ajuda a reduzir significativamente a quantidade de código repetitivo que você escreve em seus arquivos de workflow.
Você pode encontrar Actions já existentes no GitHub Marketplace, ou também pode criar suas próprias Actions e publicá-las no Marketplace.

Para saber mais sobre a criação de Actions você pode acessar: https://docs.github.com/pt/actions/creating-actions

 

Runner - Executores

Os runners são servidores que tem o aplicativo de runner do GitHub Actions instalado, eles são responsáveis por executar os workflows quando acionados. É possível usar um runner hospedado do GitHub, que podem ser: Linux, Windows ou MacOs. Mas também é possível hospedar o nosso próprio runner.

Se quiser saber mais sobre os runners auto-hospedados pode acessar: https://docs.github.com/en/actions/hosting-your-own-runners


Para configurarmos o runner no nosso workflow, utilizamos o parâmetro runs-on. No exemplo abaixo temos um workflow configurado para rodar o job de build em um runner com a última versão do ubuntu:

 

 

 

 

# .github/workflows/build.yml
name: Node CI
on: [push]
jobs:
  build:
    name: Build
    runs-on: ubuntu-latest

 

 

 

 

Criando o primeiro workflow

Agora vamos para um exemplo prático bem simples utilizando o Github Actions:
Tenho uma aplicação ASP.NET no meu repositório, e gostaria de criar um workflow para disparar um build sempre que um Pull Request for executado na master.

Dentro do repositório da aplicação nós temos a aba Actions, onde é possível encontrarmos algumas sugestões de templates de workflow para começarmos a configurar nosso build.

Mas hoje começaremos o workflow do zero, clicando em set up a workflow yourself.

 

LumaRodrigues_1-1647879509119.png

 

Primeiro, iremos dar um nome ao nosso Workflow. Essa parte não é obrigatória, mas é importante para conseguirmos visualizar e organizar melhor os nossos workflows:

 

 

 

 

name: Build ASP.NET

 

 

 

 

Vamos utilizar o parâmetro on para configurar o evento que irá disparar o nosso workflow, nesse caso será um Pull request na branch master:

 

 

 

 

name: Build ASP.NET

on:
  pull_request:
    branches: [ master ]

 

 

 

 

Agora vamos ao trabalho!

Nosso Job irá executar o build da aplicação utilizando a versão mais recente do ubuntu. Para isso, iremos definir o runner usando o parâmetro runs-on:

 

 

 

 

name: Build ASP.NET

on:
  pull_request:
    branches: [ master ]
 
jobs:
  build:
    name: Build
    runs-on: ubuntu-latest

 

 

 

 

Por fim, definimos cada etapa que o nosso build deve realizar utilizando o parâmetro steps, e vamos colocar as etapas para a publicação do artefato. Assim, quando formos fazer o deploy da nossa aplicação, conseguiremos utilizar o artefato que foi gerado nesse build.

 

 

 

 

    steps:
    - uses: actions/checkout@v2

    - name: Setup .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 5.0.x
        
    - name: Install dependencies
      run: dotnet restore
      
    - name: Build 
      run: dotnet build --configuration Release --no-restore

    - name: dotnet publish
      run: dotnet publish -c Release -o ./output
    
    - name: Upload Artifact
      uses: actions/upload-artifact@v1
      with:
        name: artifact
        path: output/

 

 

 

 

Agora nosso workflow está pronto!! :smile:

Ele deve ficar assim:

 

 

 

 

name: Build ASP.NET

on:
  pull_request:
    branches: [ master ]

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2

    - name: Setup .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 5.0.x
        
    - name: Install dependencies
      run: dotnet restore
      
    - name: Build 
      run: dotnet build --configuration Release --no-restore

    - name: dotnet publish
      run: dotnet publish -c Release -o ./output
    
    - name: Upload Artifact
      uses: actions/upload-artifact@v1
      with:
        name: artifact
        path: output/

 

 

 

 

Após a criação do PR e execução do workflow, esse foi o resultado:

 

LumaRodrigues_0-1647883819382.png

 

1 Comment
Co-Authors
Version history
Last update:
‎Mar 23 2022 08:48 AM
Updated by: