Workflow Trigger

Vamos mergulhar um pouco mais no eventos que podem ser o gatilho para um workflow. É possível fitrar os eventos de um push ao invés de mantê-lo genérico sendo acionado por qualquer push

• Filtragem de eventos
• tipos de eventos

Temos vários tipos de eventos que acionam os workflow sendo a maioria deles referentes ao repositório.

Documentação para os tipos de trigger

Vamos explorar um pouco dos principais e aprender como podem ser usados nos workflows e quando esses eventos são ocasionados.

Um dos mais importantes eventos é o push.

Podemos fazer um filtro no evento de push para que somente execute o workflow em um situação específica não em qualquer evento de push do repositório. Cada tipo de evento possui especificações para um controle granular. Sempre consulte a documentação quando necessário.

Existem eventos que possuem um tipo de atividade dentro deste evento que podemos usar, mas não estão presentes em todos os tipos de eventos somente em alguns. O evento pull_requestpossui vários tipos de atividade por exemplo opened, closed, edited, etc, no caso do push não temos esse tipo de atividade, usamos somente filtros.

push	pull_request

Se você ler a documentação do pull_request verá que se não especificarmos os tipos o padrão usado são opened, synchronize e reopened.

name: Events Demo 1
on:
  # toda vez um pull requesto for aberto será executado
  pull_request:
    types:
      - opened
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Output event data
        run: echo "${{ toJSON(github.event) }}"
      - name: Get code
        uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Test code
        run: npm run test
      - name: Build code
        run: npm run build
      - name: Deploy project
        run: echo "Deploying..."

Uma vez que declaramos os tipos de evento do pull_request para somente opened, se editarmos não idá disparar novamente o workflow.

Vamos agora adicionar o push para rodar somente em algumas branches.

on:
  push:
    branches:
      - main
      # Usamos o * para permitir variações nos nomes
      # Permite qualquer nome com o prefixo dev- e não use /
      - 'dev-*' nenhuma /
      # Dois * permitem que / sejam caracteres validos exemplo feat/new / feat/new/button
      - 'feat/**'

Também não queremos que seja para qualquer pull request, precisam estar nas branches acima, então vamos alterar.

on:
  push:
    branches:
      - main
      # Usamos o * para permitir variações nos nomes
      # Permite qualquer nome com o prefixo dev- e não use /
      - 'dev-*'
      # Dois * permitem que / sejam caracteres validos exemplo feat/new / feat/new/button
      - 'feat/**'
  pull_request:
    types:
      - opened
    branches:
      - main
      - 'dev-*'
      - 'feat/**'
  workflow_dispatch:

Você também pode filtrar com base nos caminhos dos arquivos com o filtro path presente no push e no pull request. Isso permite que você diga basicamente que deseja executar um workflow se um push ou um pull_request alterar arquivos em um caminho específico ou com paths-ignore se ele alterar qualquer coisa, exceto arquivos em uma pasta específica.

Não queremos executar quando colocarmos mais workflows ou alteramos a documentação ou o .gitignore por exemplo.

on:
  push:
    branches:
      - main
      - 'dev-*'
      - 'feat/**'
    # Ignora mudanças nos caminhos abaixo
    paths-ignore:
      - '.github/workflows/*'
      - '.gitignore'
      - docs # Uma pasta de documentação por exemplo
  pull_request:
    types:
      - opened
    branches:
      - main
      - 'dev-*'
      - 'feat/**'
  workflow_dispatch:

Vamos imaginar que alguém fez um fork do seu projeto público fez alguma alteração no código e pediu um pull request para o projeto. Ele iria cair no evento pull_request do tipo opened para a branch main e deveria executar um workflow. Porém está vindo de terceiros ele ficará com a exclamação.

Entrando no workflow temos que necessita de uma aprovação do mantenedor do projeto.

Se qualquer um pudesse ficar fazendo pull request para o seu repositório gerar uma conta absudamente alta para pagar, já pensou nisso?

Pull requests baseadas em forks não acionam um workflow mesmo que tecnicamente devesse. Quando aprovamos a primeira vez o pull request de alguém os próximos serão aceitos e rodará como esperado. Se for alguém que realmente colabore com o repositório principal talvez seja interessante colocar como colaborador dentro do repositório e evitar forks externos.

Evitando Workflows

Vamos imaginar que estamos criando o README.md de um repositório, alguma documentação ou comentando alguém código. Se dermos um push as mudanças gerarem um workflow, podemos simplesmente ignorá-los colocando uma mensagem no commit. Não faz sentido rodar um workflow enorme se não estamos alterando o que deveria ou subindo mais arquivos extras que não fazem parte do sistema.

git commit -m "Sua mensagem [skip actions]"

Qualquer um dos items abaixo se estiver na sua msg de commit não surtirá efeito no actions.

• [skip ci]
• [no ci]
• [ci skip]
• [skip actions]
• [actions skip]