Libseccomp: BUG: procure substituir o Travis CI por ações do GitHub

Aqui está um guia para migrar do TravisCI para o Github Actions. Espero experimentar isso nos próximos dias
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions / migrating-from-travis-ci-to-github-actions

Estou gostando muito do visual do Github Actions. Acabei de enviar um patchset para mudar o libcgroup do Travis CI para o Github Actions.

https://github.com/drakenclimber/libcgroup/tree/issues/github_actions
https://sourceforge.net/p/libcg/mailman/message/37165461/

Vou tentar montar um patchset para fazer a transição do libseccomp esta semana.

Isso soa bem @drakenclimber , obrigado!

Aqui está meu status atual. Tenho ações do Github trabalhando em amd64 com alguns pequenos desvios de nossa solução atual do Travis CI, mas estou preocupado com outras arquiteturas.

Prós:

• Fácil de usar. Consegui configurar rapidamente um fluxo de trabalho de integração contínua no Github Actions
• Também é fácil encapsular operações em uma ação . Essas ações podem ser reutilizadas no fluxo de trabalho. (Estranhamente, uma ação não pode invocar outra ação .)
• Velocidade aceitável (para amd64 pelo menos). Todo o conjunto de testes foi concluído em 22 minutos
• Uma boa GUI e etapas com falha são claramente delineadas
• Eu realmente gosto das opções de paralelização do Github Actions, e ele fornece um recurso para agrupar os resultados assim que outras tarefas forem concluídas. Estou usando este recurso no libcgroup para finalizar seus números de cobertura de código após todos os testes terem sido executados

Contras:

• Sem suporte nativo para outras arquiteturas
  
  
  
  • Um funcionário do github forneceu esta solução alternativa para executar um contêiner Docker arm64. Eu experimentei e, com alguma manipulação, consegui fazer com que o conjunto de testes básico funcionasse quase totalmente. (Teste 52 - carregamento básico - falhou por algum motivo estranho.) Mas essa configuração é difícil de reproduzir localmente e a depuração é um desafio significativo. Não consegui fazer os testes Python funcionarem. Ah, e é muito, muito lento - levou uma hora para executar um conjunto reduzido de testes no arm64. O ppc64el levou 6 horas antes de eu matá-lo :(
  
  
  • Um usuário do github criou esta ação que também usa contêineres Docker para executar arquiteturas não nativas. A sintaxe é um tanto desajeitada e exigiria que duplicássemos o código. Sua arquitetura com suporte
  
  
  • O Github Actions suporta o uso de runners auto-hospedados , então uma opção (feia) seria encontrar uma caixa dedicada arm64, ppc64le, etc. e usá-la para executar os testes. A vantagem disso é que a depuração seria muito mais direta do que um contêiner Docker
  
  

Outro:

• Coveralls.io criou uma ação no Github . Nossa solução TravisCI existente, cpp-coveralls , funciona no Github Actions, mas tem dificuldades com compilações paralelas. Eu tenho a ação Coveralls trabalhando em paralelo no libcgroup
• Para utilizar a ação Coveralls, tive que invocar lcov diretamente para gerar um arquivo lcov.info. Este arquivo é então carregado para coveralls.io. Observe que o uso de lcov diretamente produz números de cobertura ligeiramente diferentes. Por exemplo, a solução Travis CI não especifica se esta linha foi coberta ou não, enquanto a solução Github Actions a chama explicitamente de
• Nota para mim mesmo - não tenho o sinalizador --exclude src/arch-syscall-check.c lcov funcionando. Não tenho ideia do porque

Aqui está meu status atual. Tenho ações do Github trabalhando em amd64 com alguns pequenos desvios de nossa solução atual do Travis CI, mas estou preocupado com outras arquiteturas.

Prós:

• Fácil de usar. Consegui configurar rapidamente um fluxo de trabalho de integração contínua no Github Actions
• Também é fácil encapsular operações em uma ação . Essas ações podem ser reutilizadas no fluxo de trabalho. (Estranhamente, uma ação não pode invocar outra ação .)
• Velocidade aceitável (para amd64 pelo menos). Todo o conjunto de testes foi concluído em 22 minutos
• Uma boa GUI e etapas com falha são claramente delineadas
• Eu realmente gosto das opções de paralelização do Github Actions, e ele fornece um recurso para agrupar os resultados assim que outras tarefas forem concluídas. Estou usando este recurso no libcgroup para finalizar seus números de cobertura de código após todos os testes terem sido executados

Contras:

• Sem suporte nativo para outras arquiteturas

  • Um funcionário do github forneceu esta solução alternativa para executar um contêiner Docker arm64. Eu experimentei e, com alguma manipulação, consegui fazer com que o conjunto de testes básico funcionasse quase totalmente. (Teste 52 - carregamento básico - falhou por algum motivo estranho.) Mas essa configuração é difícil de reproduzir localmente e a depuração é um desafio significativo. Não consegui fazer os testes Python funcionarem. Ah, e é muito, muito lento - levou uma hora para executar um conjunto reduzido de testes no arm64. O ppc64el levou 6 horas antes de eu matá-lo :(
  • Um usuário do github criou esta ação que também usa contêineres Docker para executar arquiteturas não nativas. A sintaxe é um tanto desajeitada e exigiria que duplicássemos o código. Sua arquitetura com suporte
  • O Github Actions suporta o uso de runners auto-hospedados , então uma opção (feia) seria encontrar uma caixa dedicada arm64, ppc64le, etc. e usá-la para executar os testes. A vantagem disso é que a depuração seria muito mais direta do que um contêiner Docker

Outro:

• Coveralls.io criou uma ação no Github . Nossa solução TravisCI existente, cpp-coveralls , funciona no Github Actions, mas tem dificuldades com compilações paralelas. Eu tenho a ação Coveralls trabalhando em paralelo no libcgroup
• Para utilizar a ação Coveralls, tive que invocar lcov diretamente para gerar um arquivo lcov.info. Este arquivo é então carregado para coveralls.io. Observe que o uso de lcov diretamente produz números de cobertura ligeiramente diferentes. Por exemplo, a solução Travis CI não especifica se esta linha foi coberta ou não, enquanto a solução Github Actions a chama explicitamente de
• Nota para mim mesmo - não tenho o sinalizador --exclude src/arch-syscall-check.c lcov funcionando. Não tenho ideia do porque

Que tal usar o Vagrant no macOS?

Que tal usar o Vagrant no macOS?

Esse problema é especificamente sobre como mover nosso teste de CI do Travis CI para o GitHub Actions, e não sobre o desenvolvimento geral e o teste de libseccomp. Não tenho certeza se o MacOS é uma opção para Ações do GitHub e, mesmo que fosse, provavelmente seria uma escolha ruim para nós devido à falta de suporte ao kernel (nossos testes "ao vivo" são limitados, mas importantes).

Aqui está meu status atual. Tenho ações do Github trabalhando em amd64 com alguns pequenos desvios de nossa solução atual do Travis CI, mas estou preocupado com outras arquiteturas.

Obrigado por olhar para este @drakenclimber , o suporte de arquitetura limitado está muito desaparecendo. Já que não estamos vendo muitos problemas com o Travis CI no momento, talvez continuemos com o Travis até que se torne perturbador.

Em relação aos comentários do lcov / Coveralls; Eu havia notado coisas semelhantes no passado, mas não me preocupei muito com as diferenças, já que eram pequenas. Eu me pergunto se seria possível usar lcov no Travis e fazer o upload do arquivo lcov como parte da compilação do Travis sem vazar quaisquer creds na configuração do Travis. No mínimo, isso traria consistência para o uso local e do Travis, e poderia tornar as coisas um pouco mais fáceis se / quando migrarmos do Travis CI.

Que tal usar o Vagrant no macOS?

Esse problema é especificamente sobre como mover nosso teste de CI do Travis CI para o GitHub Actions, e não sobre o desenvolvimento geral e o teste de libseccomp. Não tenho certeza se o MacOS é uma opção para Ações do GitHub e, mesmo que fosse, provavelmente seria uma escolha ruim para nós devido à falta de suporte ao kernel (nossos testes "ao vivo" são limitados, mas importantes).

Estou bastante familiarizado com o GitHub Actions. Eles oferecem suporte ao macOS (consulte: https://github.com/actions/virtual-environments#available-environments). Especificamente, o macOS é o único ambiente que vem com o Vagrant e o VirtualBox (consulte: https://github.com/actions/virtual-environments/issues/433).

Na minha experiência, requer um pouco mais de trabalho para configurar, mas a execução dentro de uma máquina virtual garante um ambiente mais consistente para pipelines de CI / CD. Sem falar que é mais portátil, já que qualquer pessoa pode rodar as imagens do Vagrant / VirtualBox localmente. Também facilita a migração para uma nova solução de CI / CD, já que a configuração geralmente é escrita em um script, independente das declarações YAML específicas do fornecedor.

Estes são apenas meus dois centavos :)

Obrigado @ oxr463 , é bom saber sobre GH Actions. Neste ponto, eu preferiria não ter a sobrecarga de gerenciamento extra de um ambiente virtual, mas é algo a se considerar se o Travis CI se tornar um problema para nós.

Como nossa atividade no Travis é relativamente leve, tenho esperança de não encontrar os problemas do Travis que alguns outros projetos viram.

Obrigado por olhar para este @drakenclimber , o suporte de arquitetura limitado está muito desaparecendo. Já que não estamos vendo muitos problemas com o Travis CI no momento, talvez continuemos com o Travis até que se torne perturbador.

Sim, acho que essa é a melhor e mais segura resposta.

Em relação aos comentários do lcov / Coveralls; Eu havia notado coisas semelhantes no passado, mas não me preocupei muito com as diferenças, já que eram pequenas. Eu me pergunto se seria possível usar lcov no Travis e fazer o upload do arquivo lcov como parte da compilação do Travis sem vazar quaisquer creds na configuração do Travis. No mínimo, isso traria consistência para o uso local e do Travis, e poderia tornar as coisas um pouco mais fáceis se / quando migrarmos do Travis CI.

Sim, isso deve ser possível. Criei o problema nº 309 e o atribuí a mim mesmo. Tentarei retomar isso na próxima semana ou duas.

Obrigado

Na minha experiência, requer um pouco mais de trabalho para configurar, mas a execução dentro de uma máquina virtual garante um ambiente mais consistente para pipelines de CI / CD. Sem falar que é mais portátil, já que qualquer pessoa pode rodar as imagens do Vagrant / VirtualBox localmente. Também facilita a migração para uma nova solução de CI / CD, já que a configuração geralmente é escrita em um script, independente das declarações YAML específicas do fornecedor.

Obrigado, @ oxr463. Também espero que não tenhamos que seguir esse caminho, mas é bom saber que existem outras opções por aí.

@drakenclimber Vou retirar isso de um marco de lançamento e diminuir a prioridade para baixo, pois estamos adotando uma abordagem de "esperar até que ele quebre" para isso, se você discordar, sinta-se à vontade para gritar ou simplesmente ajustar os rótulos de acordo.

@drakenclimber Vou retirar isso de um marco de lançamento e diminuir a prioridade para baixo, pois estamos adotando uma abordagem de "esperar até que ele quebre" para isso, se você discordar, sinta-se à vontade para gritar ou simplesmente ajustar os rótulos de acordo.

Parece bom para mim. Obrigado!

@drakenclimber uma coisa acabou de me ocorrer - devemos considerar tentar migrar de travis-ci.org para travis-ci.com, já que o ".org" supostamente irá embora "em algumas semanas".

Oh! Não sabia disso. Obrigado!

Vou tentar pegar isso na próxima semana, então.