在前面几篇文章实作 GitHub Action Workflow,眼尖的读者应该会发现,我们使用是 GitHub 所提供的 Runner,我们只需指定作业系统版本、SDK 即可,不需要自行维护作业系统、网路与安装其他程序,其余的工作皆依据 workflow 定义的去执行。缺点在於若不是 public repo,会有使用时间上的限制。理所当然,倘若公司或开发人员本身就拥有服务器或虚拟机器,也可以使用自己的机器作为 Runner,除了不需要额外费用,也能高度自订专属的自动化流程,。
这种使用自己环境作为 Runner,我们称之为 Self-hosted runners
如果 Self-hosted runners 超过 30 天未连接到 GitHub Action,则会自动从 GitHub 中删除。
建议使用 Self-hosted runners 在 private repo,因为你不知道你 Fork 的 repo 是否有埋藏恶意程序
Self-hosted runners 维护上较为麻烦,除了作业系统,建置专案时所用的 SDK 也需要自行安装,如 Build Tools for Visual Studio, JDK, Android SDK...等
Self-hosted runners 从管理层面来看,可以分成三类
可以作为 Self-hosted runners 的作业系统如下
选择你的作业系统,你能发现,下方已经将安装与设定语法提供给你,只需要复制语法,在自己的环境贴上即可
我们实际行下载指令
注意:当你执行 Invoke-WebRequest -Uri https://github.com/act... 若出现下列错误
请输入:[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls"
接下来我们进行设定,依序会回答一些问题,包含 Runner Group, Runner 名称(预设服务器名称)、Label 、工作资料夹、是否注册成服务(建议选Y),服务的帐号...等
完成後,回到 GitHub Repo Runners 画面,即可看见已经连结的 Runners
若你要移除这个 Runner 之需要透过下列指令移除即可
./config.cmd --url [repo url] --token [xxx] remove
若你的 workflow 要使用这个 Self-hosted runner,只需要找到 runs-on,加上你前面设定 runner 时使用的label,依据我们的案例,改成 self-hosted 即可
runs-on: self-hosted
阅读完这篇文章,你会发现加入 Self-hosted runners 其实不难。但实际上在企业、组织中共用 Runner,要安装那些套件、如何维护才是让人头痛。在下一篇文章,我们将介绍 Runner 的另一种应用: 常见代理程序架构与部署至 IIS。
若喜欢我的文章,欢迎点 like, 分享与订阅。
https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners
<<: 【Day3】:STM32CubeIDE安装以及环境设定
昨天介绍完以搜集质化数据为强项的Hotjar之後,今天我们要介绍的是可以搜集质化和量化的工具 - M...
File message 应用 如果想写一个分析使用者传送的文章或是文件档的 Line bot,可以...
前面两天的文章中我们谈到泛型(generics)的使用,以及如何透过 extends 来限制泛型可被...
直接一点的说,今天的主题就是要让骰子动起来,现在他已经躺在那边准备好被你狠狠D甩出去了,你就不要客气...
One2one: 一对一关系,格式为: fields.One2one(关联物件 Name, 字段显示...