-
Notifications
You must be signed in to change notification settings - Fork 5
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
Pacotes plonegovbr deveriam ter mais de um job de testes #11
Comments
Pensamos num processo mais simples. https://raw.githubusercontent.com/plonegovbr/portal.buildout/master/buildout.d/versions.cfg passa a conter as pinagens que deverão constar num novo release. Dessa forma, todos os pacotes devem ter, como última linha do extends, essa url. Esse é o job padrão: referencia sempre as versões de um release ainda pendente. O segundo job, via sed, remove essa linha, dessa forma, pega diretamente do master. O que pega do master pode falhar, ver como o collective.cover faz isso. |
A última url deve ser a https://raw.githubusercontent.com/plonegovbr/portal.buildout/master/buildout.d/versions.cfg no extends. Ver plonegovbr/portalpadrao.release#11 para entender a motivação.
A última url deve ser a https://raw.githubusercontent.com/plonegovbr/portal.buildout/master/buildout.d/versions.cfg no extends. Ver plonegovbr/portalpadrao.release#11 para entender a motivação.
A "prova de conceito" envolveu brasil.gov.portal e portal.buildout, feito nas branches (já removidas) em https://github.com/plonegovbr/portal.buildout/tree/new_use_base_versions_cfg/ e https://github.com/plonegovbr/brasil.gov.portal/tree/issue_11_portalpadrao_release. Os pull requests de ambas as provas de conceitos já estão no master e a mesma idéia deve ser aplicada nos demais pacotes plonegovbr:
|
Como plonegovbr/portal.buildout#53 já foi aprovado, podemos alterar a referência à branch para ser direto do master.
Melhorar a estrutura de testes de dependências em futuros releases, evitando que muitos erros só apareçam quando é lançado o release. Implementa plonegovbr/portalpadrao.release#11
Melhorar a estrutura de testes de dependências em futuros releases, evitando que muitos erros só apareçam quando é lançado o release plonegovbr/portalpadrao.release#11
O padrão fica um pouco diferente dos demais (como em brasil.gov.portal) uma vez que a estrutura dos cfgs do buildout dele é diferente.
Melhorar a estrutura de testes de dependências em futuros releases, evitando que muitos erros só apareçam quando é lançado o release Resolve plonegovbr/portalpadrao.release#11
O padrão fica um pouco diferente dos demais (como em brasil.gov.portal) uma vez que a estrutura dos cfgs do buildout dele é diferente.
Além de travis.cfg não existir mais devido a plonegovbr/portalpadrao.release#11 as configurações aqui definidas foram implementadas em .travis.yml.
Para poder ter dois jobs. Melhorar a estrutura de testes de dependências em futuros releases, evitando que muitos erros só apareçam quando é lançado o release.
Para poder ter dois jobs ou mais jobs. Melhorar a estrutura de testes de dependências em futuros releases, evitando que muitos erros só apareçam quando é lançado o release.
Para poder ter dois jobs ou mais jobs. Melhorar a estrutura de testes de dependências em futuros releases, evitando que muitos erros só apareçam quando é lançado o release.
Para poder ter dois jobs ou mais jobs. Melhorar a estrutura de testes de dependências em futuros releases, evitando que muitos erros só apareçam quando é lançado o release.
Para atender plonegovbr/portalpadrao.release#11 preciso corrigir o code analysis de alguns arquivos.
Para atender plonegovbr/portalpadrao.release#11 preciso corrigir o code analysis de alguns arquivos.
Atualiza também o bootstrap.py.
Para atender plonegovbr/portalpadrao.release#11 preciso corrigir o code analysis de alguns arquivos.
O pacote agora tem mais de um job em integração contínua. Por causa das modificações feitas no buildout.cfg e no .travis.yml, também foi necessário corrigir o code-analysis.
O pacote agora tem mais de um job em integração contínua. Por causa das modificações feitas no buildout.cfg e no .travis.yml, também foi necessário corrigir o code-analysis.
Todos os pacotes agora possuem mais de um job de testes. |
Da forma como o buildout.cfg dos pacotes hoje é feito, ficamos presos a um release e só temos integração contínua "de verdade" quando um novo release está pra ser lançado e trocamos a versão.
A desvantagem disso é que pode ocorrer de, no lançamento de um release, o pacote ter um erro e isso tem de ser consertado: isso meio que invalida a lógica de integração contínua, que é a de visualizar os erros quando eles aparecem. Ao mesmo tempo, é útil sim testarmos com o próximo release pois alguma pinagem pode influenciar nos testes e também deve ser visto.
Assim, propomos que todos os pacotes tenham dois jobs: o tradicional, que pega do master, e um que utilize a url do úlltimo release no extends. collective.cover possui mais de um job e pode ser usado como referência. Com uso de sed, é possível adicionar uma linha numa linha x, seria possível o padrão ser o master e o do release com o uso dessa ferramenta (pode-se até pensar numa lógica de pegar o último release em portalpadrao.release ao invés de pinar manualmente a versão que sempre é alterada).
The text was updated successfully, but these errors were encountered: