Libseccomp: BUG：考虑用 GitHub 操作替换 Travis CI

这是从 TravisCI 迁移到 Github Actions 的指南。 我希望在接下来的几天内对此进行试验
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-actions/migrating-from-travis-ci-to-github-actions

我真的很喜欢 Github Actions 的外观。 我刚刚发送了一个补丁集将 libcgroup 从 Travis CI 切换到 Github Actions。

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

本周我将尝试整理一个补丁集来转换 libseccomp。

听起来不错@drakenclimber ，谢谢！

这是我目前的状态。 我有 Github Actions处理 amd64，与我们当前的 Travis CI 解决方案略有不同，但我担心其他架构。

优点：

• 使用方便。 我能够在 Github Actions 中快速设置持续集成工作流程
• 将操作封装到action 中也很容易。 然后可以在工作流中重复使用这些操作。 （奇怪的是一个动作不能调用另一个动作。）
• 可接受的速度（至少对于 amd64）。 整个测试套件在22 分钟内完成
• 清晰地描述了良好的 GUI和失败的步骤
• 我真的很喜欢 Github Actions 的并行化选项，它提供了一个功能来在其他作业完成后整理结果。 在所有测试运行后，我在 libcgroup 中使用此功能来确定其代码覆盖率数字

缺点：

• 没有对其他架构的原生支持
  
  
  
  • 一位 github 员工提供了此解决方法来运行 arm64 Docker 容器。 我试了一下，通过一些摆弄，我能够使基本测试套件大部分工作。 （测试 52 - 基本负载 - 由于某种奇怪的原因失败。）但是这种设置很难在本地重现，调试是一个重大挑战。 我无法让 python 测试工作。 哦，它真的，真的很慢 - 在 arm64 上运行一组精简的测试花了一个小时。 ppc64el在我杀死它之前
  
  
  • 一个 github 用户创建了这个操作，它也使用 Docker 容器来运行非本地架构。 语法有点笨拙，需要我们复制代码。 不过它支持的架构和平台列表非常好
  
  
  • Github Actions 支持使用自托管运行器，因此一个（丑陋的）选择是找到一个专用的 arm64、ppc64le 等框并使用它来运行测试。 这样做的好处是调试比 Docker 容器要简单得多
  
  

其他：

• Coveralls.io 创建了一个Github Action 。 我们现有的 TravisCI 解决方案cpp- coveralls 确实适用于 Github Actions，但它在并行构建方面遇到了困难。 我在libcgroup中并行运行Coveralls 操作
• 为了利用 Coveralls 的动作，我不得不直接调用 lcov来生成一个 lcov.info 文件。 然后将此文件上传到coveralls.io。 请注意，直接使用 lcov 会产生略有不同的覆盖率数字。 例如，Travis CI 解决方案没有指定该行是否被覆盖，而 Github Actions 解决方案显式地调用它未覆盖。 我相信 Github Actions 在这种情况下是正确的，我们当前的解决方案稍微误报了它的覆盖范围
• 自我注意 - 我没有--exclude src/arch-syscall-check.c lcov 标志工作。 不知道为什么

这是我目前的状态。 我有 Github Actions处理 amd64，与我们当前的 Travis CI 解决方案略有不同，但我担心其他架构。

优点：

• 使用方便。 我能够在 Github Actions 中快速设置持续集成工作流程
• 将操作封装到action 中也很容易。 然后可以在工作流中重复使用这些操作。 （奇怪的是一个动作不能调用另一个动作。）
• 可接受的速度（至少对于 amd64）。 整个测试套件在22 分钟内完成
• 清晰地描述了良好的 GUI和失败的步骤
• 我真的很喜欢 Github Actions 的并行化选项，它提供了一个功能来在其他作业完成后整理结果。 在所有测试运行后，我在 libcgroup 中使用此功能来确定其代码覆盖率数字

缺点：

• 没有对其他架构的原生支持

  • 一位 github 员工提供了此解决方法来运行 arm64 Docker 容器。 我试了一下，通过一些摆弄，我能够使基本测试套件大部分工作。 （测试 52 - 基本负载 - 由于某种奇怪的原因失败。）但是这种设置很难在本地重现，调试是一个重大挑战。 我无法让 python 测试工作。 哦，它真的，真的很慢 - 在 arm64 上运行一组精简的测试花了一个小时。 ppc64el在我杀死它之前
  • 一个 github 用户创建了这个操作，它也使用 Docker 容器来运行非本地架构。 语法有点笨拙，需要我们复制代码。 不过它支持的架构和平台列表非常好
  • Github Actions 支持使用自托管运行器，因此一个（丑陋的）选择是找到一个专用的 arm64、ppc64le 等框并使用它来运行测试。 这样做的好处是调试比 Docker 容器要简单得多

其他：

• Coveralls.io 创建了一个Github Action 。 我们现有的 TravisCI 解决方案cpp- coveralls 确实适用于 Github Actions，但它在并行构建方面遇到了困难。 我在libcgroup中并行运行Coveralls 操作
• 为了利用 Coveralls 的动作，我不得不直接调用 lcov来生成一个 lcov.info 文件。 然后将此文件上传到coveralls.io。 请注意，直接使用 lcov 会产生略有不同的覆盖率数字。 例如，Travis CI 解决方案没有指定该行是否被覆盖，而 Github Actions 解决方案显式地调用它未覆盖。 我相信 Github Actions 在这种情况下是正确的，我们当前的解决方案稍微误报了它的覆盖范围
• 自我注意 - 我没有--exclude src/arch-syscall-check.c lcov 标志工作。 不知道为什么

在 macOS 上使用 Vagrant 怎么样？

在 macOS 上使用 Vagrant 怎么样？

这个问题是专门关于将我们的 CI 测试从 Travis CI 转移到 GitHub Actions 而不是 libseccomp 的一般开发和测试。 我不确定 MacOS 是否是 GitHub Actions 的一个选项，即使它是一个选项，由于缺乏内核支持（我们的“实时”测试有限，但很重要），它对我们来说也可能是一个糟糕的选择。

这是我目前的状态。 我有 Github Actions 处理 amd64，与我们当前的 Travis CI 解决方案略有不同，但我担心其他架构。

感谢您调查此@drakenclimber ，有限的架构支持非常令人失望。 由于目前我们实际上并没有看到 Travis CI 出现很多问题，也许我们会继续使用 Travis，直到它变得具有破坏性？

关于 lcov/Coveralls 的评论； 我过去曾注意到类似的事情，但并没有太担心差异，因为它们很小。 我想知道是否可以在 Travis 中使用 lcov 并将 lcov 文件作为 Travis 构建的一部分上传，而不会泄露 Travis 配置中的任何凭据？ 如果没有其他因素会带来本地和 Travis 使用的一致性，如果/当我们从 Travis CI 迁移时，它可能会使事情变得更容易一些。

在 macOS 上使用 Vagrant 怎么样？

这个问题是专门关于将我们的 CI 测试从 Travis CI 转移到 GitHub Actions 而不是 libseccomp 的一般开发和测试。 我不确定 MacOS 是否是 GitHub Actions 的一个选项，即使它是一个选项，由于缺乏内核支持（我们的“实时”测试有限，但很重要），它对我们来说也可能是一个糟糕的选择。

我对 GitHub Actions 非常熟悉。 他们确实支持 macOS（请参阅：https://github.com/actions/virtual-environments#available-environments）。 具体来说，macOS 是 Vagrant 和 VirtualBox 附带的唯一环境（参见：https://github.com/actions/virtual-environments/issues/433）。

根据我的经验，它需要更多的设置工作，但在虚拟机内运行可确保 CI/CD 管道的环境更加一致。 更不用说，它更便携，因为任何人都可以在本地运行 Vagrant/VirtualBox 图像。 它还使迁移到新的 CI/CD 解决方案变得更容易，因为配置通常是用脚本编写的，独立于供应商特定的 YAML 声明。

这只是我的两分钱:)

谢谢@oxr463 ，很高兴了解GH Actions。 在这一点上，我不希望有虚拟环境的额外管理开销，但如果 Travis CI 成为我们的问题，这是需要考虑的。

由于我们的 Travis 活动相对较少，我希望我们不会遇到其他一些项目遇到的 Travis 问题。

感谢您调查此@drakenclimber ，有限的架构支持非常令人失望。 由于目前我们实际上并没有看到 Travis CI 出现很多问题，也许我们会继续使用 Travis，直到它变得具有破坏性？

是的，我认为这是最好和最安全的答案。

关于 lcov/Coveralls 的评论； 我过去曾注意到类似的事情，但并没有太担心差异，因为它们很小。 我想知道是否可以在 Travis 中使用 lcov 并将 lcov 文件作为 Travis 构建的一部分上传，而不会泄露 Travis 配置中的任何凭据？ 如果没有其他因素会带来本地和 Travis 使用的一致性，如果/当我们从 Travis CI 迁移时，它可能会使事情变得更容易一些。

是的，这应该是可能的。 我创建了问题 #309 并将其分配给自己。 我会在接下来的一两周内尝试解决这个问题。

谢谢

根据我的经验，它需要更多的设置工作，但在虚拟机内运行可确保 CI/CD 管道的环境更加一致。 更不用说，它更便携，因为任何人都可以在本地运行 Vagrant/VirtualBox 图像。 它还使迁移到新的 CI/CD 解决方案变得更容易，因为配置通常是用脚本编写的，独立于供应商特定的 YAML 声明。

谢谢，@oxr463。 我也希望我们不必走那条路，但很高兴知道还有其他选择。

@drakenclimber我将从发布里程碑中删除它并将优先级降低到低，因为我们正在采用“等到它崩溃”的方法来解决这个问题，如果您不同意，请随时大喊或简单地相应地调整标签。

@drakenclimber我将从发布里程碑中删除它并将优先级降低到低，因为我们正在采用“等到它崩溃”的方法来解决这个问题，如果您不同意，请随时大喊或简单地相应地调整标签。

听起来不错。 谢谢！

@drakenclimber我刚刚发生了一件事——我们应该考虑尝试从 travis-ci.org 迁移到 travis-ci.com，因为“.org”应该会在“几周内”消失。

哦！ 不知道。 谢谢！

下周我会试着把它捡起来。