Libseccomp: RFE: Transição de travis-ci.org para travis-ci.com

Criado em 19 jan. 2021  ·  10Comentários  ·  Fonte: seccomp/libseccomp

travis-ci.org está sendo desativado e será removido em um futuro próximo.

Siga as etapas aqui para fazer a transição de libseccomp para o novo site travis-ci.com.
https://docs.travis-ci.com/user/migrate/open-source-repository-migration

enhancement priorithigh

Todos 10 comentários

Eu entrei no travis-ci.com, mas eles ainda estão na fase beta, portanto, ainda não podemos fazer a transição.

Bah! Eles definitivamente não estão facilitando as coisas, estão? ;)

Como o prazo de transição ainda é "nebuloso", para dizer o mínimo, vou puxar isso do marco v2.5.2 e deixá-lo flutuar. Ainda precisaremos examinar isso em algum momento, mas até que Travis se mova, não há nada que possamos fazer aqui.

Acabei de verificar se a compilação do Travis foi concluída corretamente após alguns envios e fui recebido por esta mensagem:

Desde 15 de junho de 2021, a construção em travis-ci.org foi encerrada. Por favor, use travis-ci.com de agora em diante.

... parece que precisamos descobrir isso, e logo.

Estou um pouco desconfiado do novo modelo de negócios de Travis. Parece que o código-fonte aberto permanecerá gratuito (por enquanto), mas eles não tornaram isso fácil. Podemos precisar solicitar periodicamente mais "créditos" deles.
https://docs.travis-ci.com/user/billing-faq/#what -if-i-am-building-open-source

What if I am building open source? #

Each of the Travis CI Plans contains an amount of special OSS credits per month assigned to
run builds only on public repositories. To find out more about it please contact the Travis CI
support team. In the email please include:

* Your account name and your VCS provider (like travis-ci.com/github/[your account name] )
* How many credits (build minutes) you’d like to request (should your run out of credits again
  you can repeat the process to request more or to discuss a renewable amount)

Ugh, isso é péssimo: /

Preciso refrescar minha memória sobre o que você descobriu sobre GH Actions; estava longe de ser perfeito, mas considerando as mudanças do Travis CI, pode ser a melhor opção.

Aqui vamos nós ... # 299

Ok, tendo atualizado minha memória no # 299, acho que a melhor opção agora é migrar para ações do GH e ficar apenas nos builds de CI x86_64 por enquanto. Esse parece ser o caminho mais rápido para restaurar os testes de cobertura de PR / branch e código com o mínimo de dor de cabeça.

A falta de outros arcos / ABIs é preocupante, mas realisticamente não testamos todos os arcos / ABI regularmente (como poderíamos?), Então este não é o fim do mundo. Se ajudar, embora não seja "CI", eu tenho um trabalho noturno que é executado em alguma infraestrutura privada que constrói e verifica o branch principal libseccomp em aarch64; se algo quebrar, notarei em aproximadamente 24 horas. Espero que possamos descobrir algo melhor no futuro (tenho algumas ideias aqui ...).

pensamentos @drakenclimber ?

Acho que a melhor opção agora é migrar para ações do GH e ficar apenas com os builds de CI x86_64 por enquanto. Esse parece ser o caminho mais rápido para restaurar os testes de cobertura de PR / branch e código com o mínimo de dor de cabeça.

Parece bom para mim. Eu posso possuir a transição, pois já fiz isso para libcgroup.

Temos usado Github Actions no libcgroup por um bom tempo e funcionou muito bem. Os trabalhos foram fáceis de transferir do Travis.

As VMs do Github Actions não forneciam um recurso de que precisávamos no libcgroup (um sistema cgroup v2 completo), então recentemente criei uma VM no Oracle Free Cloud e conectei por meio do runner auto-hospedado do Github Actions. Foi fácil de configurar e até agora funcionou bem. Acredito que a lógica de execução auto-hospedada do GH Actions oferece suporte a aarch64, portanto, essa poderia ser uma maneira de testar continuamente o ARM se tivéssemos uma caixa para a qual pudéssemos apontá-lo.

A falta de outros arcos / ABIs é preocupante, mas realisticamente não testamos todos os arcos / ABI regularmente (como poderíamos?), Então este não é o fim do mundo.

Concordou. Eu gostei da variedade de arquiteturas testadas atualmente, já que ocasionalmente são encontradas problemas estranhos de 32 x 64 bits e big vs little endian. Antes de um lançamento, devemos (no mínimo) executar os testes em outras arquiteturas. Talvez possamos recrutar contribuidores anteriores para ajudar aqui.

(Eu tenho algumas idéias aqui ...).

Sou todo ouvidos. Eu gostaria de poder pegar as melhores partes do GH Actions e do Travis e colocá-las em um CI.

(Tenho algumas ideias aqui ...)

Desculpe, eu deveria ter sido mais claro. Eu quis dizer que posso ter algumas idéias sobre o suporte aarch64, não sobre Travis / GH em geral.

Independentemente disso, obrigado por trabalhar nisso no PR # 329.

Esta página foi útil?
0 / 5 - 0 avaliações