Cuidado com os custos escondidos

Se você verificar nesta página os custos do github actions é cobrado por MINUTO

Ok, mas o que acontece se a action demorar 5 segundos para executar? Vai ser cobrado um minuto inteiro

Lendo o seu workflow vemos que tem diversos passos que se repetem entre os jobs:

 steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Use Node.js 20.x
        uses: actions/setup-node@v3
        with:
          node-version: 20.x
          cache: 'yarn'

      - name: Install Dependencies
        run: yarn install

essas ações vão consumir tempo desnecessário!

Otimizando essa action

Porquê não fazer em um único job o teste e o deploy?

name: Build and Deploy

on:
  push:
    branches: 'main'
  pull_request:
    branches: 'main'

jobs:
  tests:
    name: Run Tests
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Use Node.js 20.x
        uses: actions/setup-node@v3
        with:
          node-version: 20.x
          cache: 'yarn'

      - name: Install Dependencies
        run: yarn install

      - name: Run Tests
        run: yarn test

      - name: Run Build
        run: yarn build

Isso irá diminuir MUITO o tempo para rodar o flow, se ocorrer em uma organização grande pode ter certeza que fará diferença no orçamento mensal

Erro 1: O que está sendo feito com o build?

No último passo é executado o build:

- name: Run Build
  run: yarn build

mas cadê o commit?

Esse build simplesmente será descartado assim que a action terminar de executar.

Erro 2: O mesmo fluxo ocorrendo em 2 momentos diferentes

Ok, não chega a ser um erro, mais uma sugestão pessoal

on:
  push:
    branches: 'main'
  pull_request:
    branches: 'main'

Porque o mesmo fluxo ocorre nesses 2 momentos? se o teste passou no Pull request não precisa testar novamente na main! Assim como buildar no pull request pode remover uma build de uma main mais atualizada.

Vou tentar exclarecer melhor:

Main        Branch A         Branch B
  |
  |-------------+----------------+
  |             |                |
  |             | Commit 1       |
  |             |                |
  | <-----------+ PR 1           |
  |                              | Commit 2
  |                              |
  | <----------------------------+ PR 2
  |

No momento que é solicitado o PR 2 vai gerar uma nova build. Se esse PR for aceito vai acontecer uma das situações:

• A build do PR 2 vai apagar totalmente o PR 1 por um momento
• Vai dar conflito de merge
• Vai ficar inconsistente com arquivos de cada build misturados

Solução que utilizo

Deploy apenas quando foi aprovado o PR

# DEPLOY
on:
  push:
    branches: 'main'

Testes apenas no pull request

# TESTES
on:
  pull_request:
    branches: 'main'