Configurar Integração Contínua usando GitHub Actions

Documentação Guias do Desenvolvedor
,
1

:mag: Visão Geral

Para construir uma extensão robusta para o Discourse, pode ser prudente incluir Integração Contínua (CI) no seu plugin ou componente de tema. Isso ajudará a detectar erros precocemente e diminuir as chances de bugs no seu código.

Configurar um fluxo de trabalho de :abbr title=“Continuous Integration”>CI usando GitHub Actions para automatizar compilações e testes é uma abordagem que a equipe do Discourse usa em todos os nossos componentes, e recomendamos que você faça o mesmo.

:gear: Configurando

Para adicionar fluxos de trabalho automatizados para o GitHub Actions detectar, você precisa criar uma pasta .github/workflows no diretório raiz do seu repositório.

Dentro da pasta workflows, você pode definir um conjunto de automações que o GitHub Actions precisará executar. Por exemplo, estes podem ser arquivos .yml para linting e testes.

Criamos fluxos de trabalho de modelo tanto para plugins quanto para componentes de tema que você pode utilizar. Eles se conectam às nossas definições de ‘fluxo de trabalho reutilizável’ aqui.

No repositório esqueleto do modelo, no GitHub, você pode clicar no botão :kbd:Use this template para criar um repositório de plugin/componente de tema baseado no modelo.

Alternativamente, se você já tem um projeto ao qual deseja adicionar os fluxos de trabalho, simplesmente copie o fluxo de trabalho relevante para a pasta .github/workflows/ do seu repositório:

:electric_plug: Plugins: discourse-plugin.yml

:jigsaw: Temas e Componentes de Tema: discourse-theme.yml

:point_up: Esses modelos estão fixados em uma versão principal específica dos nossos fluxos de trabalho reutilizáveis. Pequenas melhorias que fizermos nos fluxos de trabalho terão efeito automático no seu tema/plugin. Para alterações que quebram a compatibilidade (por exemplo, introduzir um novo linter), aumentaremos a versão principal dos fluxos de trabalho reutilizáveis, e você precisará atualizar seu fluxo de trabalho para apontar para a nova versão.

:tada: Pronto! Você está configurado! Simplesmente, crie um commit ou um :abbr title=“Pull Request”>PR no seu repositório e o GitHub Actions detectará automaticamente os fluxos de trabalho e começará a executar os trabalhos.

O GitHub Actions mostrará um detalhamento de cada teste e, após a execução, indicará um :white_check_mark: ou :x: dependendo se o teste passou ou falhou.

Se um teste falhou, clicar nos detalhes fornecerá algumas informações sobre o que falhou, o que pode dar pistas sobre o que está errado com seu código e o que precisa ser corrigido.

Ver exemplo

example failure
example failure2192×1018 250 KB

:white_check_mark: Adicione seus próprios testes

Para que os testes de plugin e componentes funcionem de forma eficaz, é importante que você escreva testes para o seu plugin ou componente de tema.

Para detalhes sobre como escrever testes de front-end com EmberJS, consulte:

Para mais detalhes sobre como escrever testes RSpec com Rails, consulte:

:bulb: Exemplos

Para sua conveniência, selecionamos alguns exemplos de plugins e componentes de tema que têm testes robustos integrados:

Plugin / Componente Testes do Lado do Cliente Testes do Lado do Servidor
Assign :link: Ver Pasta :link: Ver Pasta
Calendar :link: Ver Pasta :link: Ver Pasta
Reactions :link: Ver Pasta :link: Ver Pasta
Right Sidebar Blocks :link: Ver Pasta
Tag Icons :link: Ver Pasta
Table Builder :link: Ver Pasta

Este documento é controlado por versão - sugira alterações no github.

15 curtidas
How could a CI workflow for unofficial plugins be implemented?
Unexpected error in Discourse Plugin CI
6

Você pode mencionar explicitamente GitHub - discourse/discourse-theme-skeleton: Template for Discourse themes e observar que você deve acompanhá-lo para tomar nota das alterações nesses arquivos.

4 curtidas
7

Espero que os fluxos de trabalho reutilizáveis possam ser mesclados, tornando esta parte menos relevante, pois novos repositórios feitos a partir do modelo usarão os fluxos de trabalho diretamente do repositório do modelo.

2 curtidas
8

Obrigado @pfaffman e @Simon_Manning, bons pontos. Atualizei o OP de acordo.

4 curtidas
9

Atualizei o OP para incluir instruções para usar nossos novos ‘fluxos de trabalho reutilizáveis’. Pequenas alterações que fazemos nas definições do fluxo de trabalho agora podem ser aplicadas automaticamente aos seus temas/plugins sem nenhum trabalho manual.

3 curtidas
10

Preciso fazer algo especial para que um plugin seja testado contra os testes mais recentes e que estejam passados e estáveis?

1 curtida
11

O fluxo de trabalho de esqueleto de plugin usa o seguinte, que acho que testará contra o branch padrão, então main. O fluxo de trabalho reutilizável tem uma entrada opcional core_ref e, pelo que pude apurar, sem ela, o branch padrão do repositório discourse/discourse será verificado.

jobs:
  ci:
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1

Não posso dizer se isso realmente o limita a testar contra main ou não, mas se sim, você pode adicionar uma estratégia de matriz para executar uma vez para cada ref contra a qual deseja testar.

jobs:
  ci:
    strategy:
      matrix:
        target: [tests-passed, stable]
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1
    with:
      core_ref: ${{ matrix.target }}
3 curtidas
12

Sim, isso deve resolver. Ou você pode simplesmente escrever os dois trabalhos manualmente sem usar uma matriz:

name: Discourse Plugin

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  ci:
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1

  ci-stable:
    uses: discourse/.github/.github/workflows/discourse-plugin.yml@v1
    with:
      core_ref: stable

Vale notar, no entanto: esses trabalhos não verificarão .discourse-compatiblity. Portanto, isso só vale a pena fazer em plugins que não usam esse arquivo e precisam ser compatíveis com main e stable simultaneamente.

Para todos os temas/plugins públicos da CDCK, adicionamos uma entrada ao discourse-compatibility para ‘congelá-los’ em cada lançamento estável. Assim, não precisamos nos preocupar com a compatibilidade estável enquanto os desenvolvemos.

5 curtidas
13

Obrigado a ambos.

Sim, essa é provavelmente a abordagem mais direta. A única desvantagem é que potencialmente atrasa recursos (e novas correções de bugs)

2 curtidas