Libseccomp: バグ：TravisCIをGitHubアクションに置き換えることを検討してください

TravisCIからGithubActionsに移行するためのガイドは次のとおりです。 今後数日間でこれを試してみたいと思っています
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions / migrating-from-travis-ci-to-github-actions

GithubActionsの外観が本当に気に入っています。 libcgroupをTravisCIからGithubActionsに切り替えるパッチセットを送信しました。

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

今週はlibseccompを移行するためのパッチセットをまとめようと思います。

それはいいですね

これが私の現在の状況です。 現在のTravisCIソリューションからわずかに逸脱したamd64で動作させていますが、他のアーキテクチャについて懸念があります。

長所：

• 使いやすい。 GithubActionsで継続的インテグレーションワークフローをすばやくセットアップできました
• 操作をアクションにカプセル化するのも簡単です。 これらのアクションは、ワークフロー内で再利用できます。 （不思議なことに、アクションは別のアクションを呼び出すことができません。）
• 許容可能な速度（少なくともamd64の場合）。 テストスイート全体が22分で完了しました
• 優れたGUIと失敗した手順が明確に示されている
• 私はGithubActionsの並列化オプションが本当に好きで、他のジョブが完了したら結果を照合する機能を提供します。 すべてのテストが実行された後、libcgroupでこの機能を使用して、コードカバレッジ数を

短所：

• 他のアーキテクチャのネイティブサポートはありません
  
  
  
  • githubの従業員は、arm64Dockerコンテナを実行するためにこの回避策を提供しました。 私はそれを試してみましたが、少し手を加えることで、基本的なテストスイートをほぼ機能させることができました。 （テスト52-基本的なロード-何らかの奇妙な理由で失敗しました。）しかし、このセットアップをローカルで再現することは困難であり、デバッグは重要な課題です。 Pythonテストを機能させることができませんでした。 ああ、それは本当に、本当に遅いです-arm64で簡素化された一連のテストを実行するのに1時間かかりました。 ppc64elは私がそれを殺す前に
  
  
  • githubユーザーは、Dockerコンテナを使用して非ネイティブアーキテクチャを実行するこのアクションを作成しました。 構文はやや不格好で、コードを複製する必要があります。 サポートされているアーキテクチャとプラットフォームのリストはかなり良いですが
  
  
  • Github Actionsはセルフホストランナーの使用をサポートしているため、1つの（醜い）オプションは、専用のarm64、ppc64leなどのボックスを見つけてそれを使用してテストを実行することです。 これの利点は、デバッグがDockerコンテナよりもはるかに簡単になることです。
  
  

他の：

• Coveralls.ioはGithubアクションを作成しました。 既存のTravisCIソリューションであるcpp- coverallsは、Github Actionsで機能しますが、並列ビルドで苦労しました。 libcgroupでを並行します
• Coverallsのアクションを利用するには、 lcovを直接呼び出してlcov.infoファイルを生成する必要がありました。 次に、このファイルはcoveralls.ioにアップロードされます。 lcovを直接使用すると、わずかに異なるカバレッジ数が生成されることに注意してください。 たとえば、Travis CIソリューションでは、この行がカバーされているかどうかは指定されていませんが、GithubActionsソリューションでは明示的にカバーされていないと呼ばれています。 この場合、Github Actionsは正しいと思います。現在のソリューションでは、カバレッジ数がわずかに誤って報告されています。
• 自己メモ- --exclude src/arch-syscall-check.c lcovフラグが機能していません。 理由がわからない

これが私の現在の状況です。 現在のTravisCIソリューションからわずかに逸脱したamd64で動作させていますが、他のアーキテクチャについて懸念があります。

長所：

• 使いやすい。 GithubActionsで継続的インテグレーションワークフローをすばやくセットアップできました
• 操作をアクションにカプセル化するのも簡単です。 これらのアクションは、ワークフロー内で再利用できます。 （不思議なことに、アクションは別のアクションを呼び出すことができません。）
• 許容可能な速度（少なくともamd64の場合）。 テストスイート全体が22分で完了しました
• 優れたGUIと失敗した手順が明確に示されている
• 私はGithubActionsの並列化オプションが本当に好きで、他のジョブが完了したら結果を照合する機能を提供します。 すべてのテストが実行された後、libcgroupでこの機能を使用して、コードカバレッジ数を

短所：

• 他のアーキテクチャのネイティブサポートはありません

  • githubの従業員は、arm64Dockerコンテナを実行するためにこの回避策を提供しました。 私はそれを試してみましたが、少し手を加えることで、基本的なテストスイートをほぼ機能させることができました。 （テスト52-基本的なロード-何らかの奇妙な理由で失敗しました。）しかし、このセットアップをローカルで再現することは困難であり、デバッグは重要な課題です。 Pythonテストを機能させることができませんでした。 ああ、それは本当に、本当に遅いです-arm64で簡素化された一連のテストを実行するのに1時間かかりました。 ppc64elは私がそれを殺す前に
  • githubユーザーは、Dockerコンテナを使用して非ネイティブアーキテクチャを実行するこのアクションを作成しました。 構文はやや不格好で、コードを複製する必要があります。 サポートされているアーキテクチャとプラットフォームのリストはかなり良いですが
  • Github Actionsはセルフホストランナーの使用をサポートしているため、1つの（醜い）オプションは、専用のarm64、ppc64leなどのボックスを見つけてそれを使用してテストを実行することです。 これの利点は、デバッグがDockerコンテナよりもはるかに簡単になることです。

他の：

• Coveralls.ioはGithubアクションを作成しました。 既存のTravisCIソリューションであるcpp- coverallsは、Github Actionsで機能しますが、並列ビルドで苦労しました。 libcgroupでを並行します
• Coverallsのアクションを利用するには、 lcovを直接呼び出してlcov.infoファイルを生成する必要がありました。 次に、このファイルはcoveralls.ioにアップロードされます。 lcovを直接使用すると、わずかに異なるカバレッジ数が生成されることに注意してください。 たとえば、Travis CIソリューションでは、この行がカバーされているかどうかは指定されていませんが、GithubActionsソリューションでは明示的にカバーされていないと呼ばれています。 この場合、Github Actionsは正しいと思います。現在のソリューションでは、カバレッジ数がわずかに誤って報告されています。
• 自己メモ- --exclude src/arch-syscall-check.c lcovフラグが機能していません。 理由がわからない

macOSでVagrantを使用するのはどうですか？

macOSでVagrantを使用するのはどうですか？

この問題は特に、CIテストをTravisCIからGitHubActionsに移行することに関するものであり、libseccompの一般的な開発とテストに関するものではありません。 MacOSがGitHubActionsのオプションであるかどうかはわかりません。たとえそうだったとしても、カーネルサポートがないため、私たちにとっては不適切な選択である可能性があります（「ライブ」テストは限られていますが、重要です）。

これが私の現在の状況です。 現在のTravisCIソリューションからわずかに逸脱したamd64で動作するGithubActionsがありますが、他のアーキテクチャについて懸念があります。

この@drakenclimberを調べてくれてありがとう、限られたアーキテクチャのサポートは非​​常に残念です。 現在、Travis CIで実際に多くの問題が発生しているわけではないので、混乱が生じるまでTravisを継続するのではないでしょうか。

lcov / Coverallsのコメントについて; 過去に似たようなことに気づきましたが、違いは小さいのであまり気にしませんでした。 Travisでlcovを使用し、Travis構成の資格情報をリークすることなく、Travisビルドの一部としてlcovファイルをアップロードすることは可能でしょうか？ ローカルとTravisの使用全体で一貫性をもたらすものが他にない場合、Travis CIから移行する場合は、状況が少し簡単になる可能性があります。

macOSでVagrantを使用するのはどうですか？

この問題は特に、CIテストをTravisCIからGitHubActionsに移行することに関するものであり、libseccompの一般的な開発とテストに関するものではありません。 MacOSがGitHubActionsのオプションであるかどうかはわかりません。たとえそうだったとしても、カーネルサポートがないため、私たちにとっては不適切な選択である可能性があります（「ライブ」テストは限られていますが、重要です）。

私はGitHubActionsに精通しています。 それらはmacOSをサポートします（https://github.com/actions/virtual-environments#available-environmentsを参照）。 具体的には、macOSはVagrantとVirtualBoxに付属している唯一の環境です（https://github.com/actions/virtual-environments/issues/433を参照）。

私の経験では、セットアップにはもう少し作業が必要ですが、仮想マシン内で実行すると、CI / CDパイプラインの環境の一貫性が高まります。 言うまでもなく、誰でもVagrant / VirtualBoxイメージをローカルで実行できるため、より移植性が高くなります。 また、構成は通常、ベンダー固有のYAML宣言とは関係なくスクリプトで記述されるため、新しいCI / CDソリューションへの移行が容易になります。

これは私の2セントです:)

@ oxr463に感謝します

私たちのTravisの活動は比較的軽いので、他のいくつかのプロジェクトで見られたTravisの問題に遭遇しないことを願っています。

この@drakenclimberを調べてくれてありがとう、限られたアーキテクチャのサポートは非​​常に残念です。 現在、Travis CIで実際に多くの問題が発生しているわけではないので、混乱が生じるまでTravisを継続するのではないでしょうか。

はい、それが最善かつ最も安全な答えだと思います。

lcov / Coverallsのコメントについて; 過去に似たようなことに気づきましたが、違いは小さいのであまり気にしませんでした。 Travisでlcovを使用し、Travis構成の資格情報をリークすることなく、Travisビルドの一部としてlcovファイルをアップロードすることは可能でしょうか？ ローカルとTravisの使用全体で一貫性をもたらすものが他にない場合、Travis CIから移行する場合は、状況が少し簡単になる可能性があります。

はい、これは可能であるはずです。 Issue＃309を作成し、自分に割り当てました。 私は来週か2週間でこれを拾おうとします。

ありがとう

私の経験では、セットアップにはもう少し作業が必要ですが、仮想マシン内で実行すると、CI / CDパイプラインの環境の一貫性が高まります。 言うまでもなく、誰でもVagrant / VirtualBoxイメージをローカルで実行できるため、より移植性が高くなります。 また、構成は通常、ベンダー固有のYAML宣言とは関係なくスクリプトで記述されるため、新しいCI / CDソリューションへの移行が容易になります。

ありがとう、@ oxr463。 また、そのルートに行く必要がないことを願っていますが、他にも選択肢があることを知っておくとよいでしょう。

@drakenclimberこれをリリースマイルストーンから削除し、優先度を低に下げます。これには「壊れるまで待つ」アプローチを採用しているためです。同意できない場合は、

@drakenclimberこれをリリースマイルストーンから削除し、優先度を低に下げます。これには「壊れるまで待つ」アプローチを採用しているためです。同意できない場合は、

私にはいいですね。 ありがとう！

@drakenclimber 1つのことが私に起こりました。「。org」は「数週間以内に」なくなると思われるため、travis-ci.orgからtravis-ci.comに移行することを検討する必要があります。

おー！ それを知りませんでした。 ありがとう！

来週はこれを拾おうと思います。