自托管 github 运行器在哪里执行代码？在同一台机器上拥有多个跑步者是一种好习惯吗？

Question

最近我尝试在我的自托管 GitHub 运行器上运行构建测试。我知道它在其隔离的虚拟环境中运行并在执行结束时破坏环境（如果我错了，请纠正我）。现在如果我们想控制环境进行调试，我们如何才能访问这个虚拟环境？

为了安装多个跑步者，我为多个跑步者创建了多个文件夹，这样我就可以使用同一台机器并行运行我的测试。如果它们在隔离的虚拟环境中运行，一个运行器的执行是否有可能会中断其他运行器的执行？

Answer 1

自托管 github runner 在哪里执行代码？

我知道它在其隔离的虚拟环境中运行并在执行结束时破坏环境（如果我错了，请纠正我）

这仅适用于 GitHub 托管的运行器，但不适用于自托管的运行器。与 GitHub 托管的运行器相比，自托管运行器的实现方式略有不同。根据the documentation

每个 GitHub 托管的运行器始终是一个干净的隔离虚拟机，并在作业执行结束时被销毁

自托管运行器被实现为常规进程，没有虚拟化或与运行它们的操作系统隔离。这意味着由 GitHub 操作工作流作业执行引起的任何副作用对操作系统中运行的每个进程都是可见的。任何文件系统修改也会在工作流的执行中保持不变（例如，安装依赖项将对稍后在同一运行器上执行的其他工作流可见，甚至对设置在同一操作系统上的其他运行器可见 - 就像你的情况一样）。因此，您必须注意一旦设置了运行器，它在执行作业之间是有状态的。这个事实暗示了一些security drawbacks。您可以阅读更多关于 GitHub 托管和自托管运行器之间的区别here。

现在如果我们想控制环境进行调试，我们如何才能访问这个虚拟环境？

基本调试功能以多个运行器logging levels 的形式提供。如果这还不够，您还可以使用专用的tmate debug action 或搜索您可以在GitHub Marketplace 上找到的其他调试相关操作

如果在隔离的虚拟环境中运行，一个运行器的执行是否有可能会中断其他运行器的执行？

如上所述，自托管运行器不使用虚拟环境，而是使用现有的操作系​​统环境。但是，在同一操作系统上设置的每个运行器都独立于其他运行器执行工作流作业。当然，一个跑步者的工作引起的特定副作用可能会对另一个跑步者产生负面影响。例如，如果您在一个运行器上执行的集成测试在给定静态端口上启动了所需的 http 服务器，那么相同的测试将使在另一个运行器上设置的 http 服务器失败，因为该端口将不可用。

在同一台机器上拥有多个跑步者是一种好习惯吗？

一如既往，视情况而定。一般来说，在同一个操作系统上设置多个自托管运行器并没有什么问题。我自己多次使用这种方法。但是，如果您有我提到的问题（隔离、可能会干扰作业执行运行的负面副作用、安全问题等），那么您应该重新考虑该方法。