Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Melhorar gatilhos para workflows dependentes dos deploys de preview #13

Open
thlmenezes opened this issue Aug 16, 2022 · 0 comments
Open

Comments

@thlmenezes
Copy link
Collaborator

Sua solicitação de recurso está relacionada a um problema? Por favor, descreva.

Depender de sleeps e healthchecks para a boa execução do fluxo de validação automático adiciona um grau de incerteza não ideal para o contexto de CI/CD. Vejamos o exemplo abaixo:

- run: sleep 180
- name: Waiting for 200 from the Vercel Preview
  uses: patrickedqvist/[email protected]
  id: vercelPreview
  with:
    token: ${{ secrets.GITHUB_TOKEN }}
    max_timeout: 120

Caso dentro desse período não haja um novo deploy de preview, a validação não será executada.

Descreva a solução desejada

Temos os seguintes objetivos:

  1. Cancelar graciosamente ou não executar fluxos de trabalho, caso não haja novo deploy
  2. Alterar gatilhos dos fluxos de trabalho, mantendo feedbacks automatizados no PR
    2.1 lighthouse.yml
    2.2 e2e.yml

Baseado nesse artigo, uma implementação possível é:

Ambos fluxos de trabalho

  • Modificar evento para deployment_status
  • Filtrar execução usando:
if: github.event.deployment_status.environment == 'Preview' && github.event.deployment_status.state == 'success'
  • Poderia remover a verificação de preview nas validações do lighthouse.yml
  • Utilizar url vindo de ${{ github.event.deployment_status.target_url }}

lighthouse.yml

Além dos ajustes anteriores, para manter os comentários de revisão

Descreva as alternativas que você considerou

Pesquisei outros fluxos de trabalho disponíveis no github marketplace, mas não encontrei nenhuma que considerava os casos de PRs que não alteram código que ativa a geração de uma nova versão do site. Todas as alternativas com manutenção suficiente para serem consideradas eram baseadas na mesma abordagem de sleeps e healthchecks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant