Convido vocês a compartilhar ideias sobre possíveis fluxos de trabalho de CI, que executariam testes em plugins não oficiais fornecidos pela comunidade.
Algumas comunidades dependem fortemente de plugins, sem manutenção estabelecida:
Como os testes de plugins dependem de uma instalação do Discourse como banco de testes, pergunto como seria um fluxo de trabalho de CI apoiado pela comunidade.
Alguns plugins incluem especificações, como a implementação do @angus do activitypub, que, pelo que entendi, permitem testes para CI.
Atualmente, penso em duas maneiras possíveis de melhorar os testes de plugins não oficiais, dependendo de especificações / testes incluídos no código-fonte do plugin:
a) construir alguma estrutura que ajude os mantenedores do site a executar testes em um ambiente de staging
b) ter algum serviço que crie um fork de uma imagem de teste predefinida para relatar os testes executados no último código publicado do plugin.
Além de CI com testes de backend e frontend, que a maioria dos plugins do Pavilion agora possui, temos um sistema de gerenciamento de plugins do qual CI é uma parte. É assim que funciona
Que exibe o status das verificações de compatibilidade dos Plugins Pavilion (e às vezes outros) contra tests-passed e stable. Isso é atualizado todos os dias, automaticamente.
Isso, é claro, depende de testes, incluindo testes de fumaça, specs (backend) e testes qunit (frontend).
Nosso plugin de assinatura (Custom Wizard) tem a maior cobertura de testes, como você pode imaginar, mas alguns de nossos plugins gratuitos incluem um bom conjunto de testes de backend e frontend (por exemplo, Locations).
Escrever testes é uma boa prática e certamente o Pavilion se tornou ainda mais disciplinado nesse espaço à medida que amadurecemos como negócio.
Criticamente, os testes também documentam sua funcionalidade pretendida, o que é extremamente importante, especialmente durante atualizações de compatibilidade ou refatoração.
É uma arquitetura conforme o diagrama de @angus, com vários repositórios envolvidos, mas este é o servidor de status:
É também uma abordagem:
Nunca implemente uma correção sem verificar se há um teste e, se um teste adequado não existir, adicione um.
De preferência, desenvolva o teste primeiro, mostre que ele falha, depois corrija o problema e confirme que seu novo teste passa.
Dessa forma, sua cobertura aumenta ao longo do tempo…
Além disso:
Adaptar testes retroativamente pode ser arriscado, pois você pode interpretar mal o que o código pretendia fazer… melhor do que não fazer nada, no entanto…
Todos os plugins oficiais têm especificações que você pode usar como exemplos. O plugin discourse-plugin-Skelton inclui Ações do GitHub para executar testes em cada commit, e acho que diariamente.
a) Isso está disponível via GitHub actions: plugins com especificações/testes adequados usando GitHub actions terão um selo no GitHub, se todos os testes passarem e o status das ações de CI for legível pela API.
b) Exceto pelos plugins oficiais do Discourse e plugins do Pavilion, não existe uma visão geral automática para administradores, se os plugins em uso funcionarão na versão pretendida para atualização?
Pelo que entendi, esta é uma solução para o problema inverso: Discourse muito antigo para um plugin.
Como tratar o outro caminho: plugin muito antigo para o Discourse?
O /admin/upgrade poderia alertar sobre plugins que falham nos testes para uma atualização pretendida?
Originalmente, propusemos e fornecemos uma versão sem marca de nosso painel de plugins onde autores terceirizados poderiam apresentar seus plugins para inclusão. Isso não ganhou tração, em parte porque a população de desenvolvedores de plugins de terceiros é muito pequena.
A criação de plugins de terceiros para Discourse é bastante nichada e o fornecimento de plugins com boa cobertura de testes por terceiros é muito nichado!
Muitos dos freelancers neste espaço se juntaram ao Pavilion ou à CDCK (ou, com o tempo, a ambos!)
Então, no final, decidimos simplesmente incorporar nosso painel em nosso site comunitário de marca.
