blog
blog copied to clipboard
qiwihui
技术和思考，基于issues
GitHub Actions 具有许多强大的组件，但是当你开始一起使用它们时，事情就开始变得真正强大。例如：矩阵工作流使你可以轻松地将简单的工作流扩展到多个不同的作业。通过条件执行，你可以限制作业中步骤的执行。 这两个功能很自然地结合在一起──当你跨不同的操作系统，平台或语言版本构建矩阵时，可能只需要在该矩阵的一个子集上运行一些步骤。例如：在Linux上运行时，可能需要安装其他编译器，或者对于不同的操作系统，可能需要安装稍有不同的依赖项。 我可以结合一些以前的概念来为我的一个项目（C语言中的系统库）构建工作流。它将使用[跨平台](https://qiwihui.com/qiwihui-blog-86/)和[工具安装](https://qiwihui.com/qiwihui-blog-87/)的[矩阵工作流](https://qiwihui.com/qiwihui-blog-85/)来执行CI的构建和测试步骤。 目标是安装Ninja构建系统，然后使用CMake创建构建脚本以利用这一优势──CMake和Ninja可以很好地协同工作，以生成快速，跨平台的本机构建。最后，我们将使用 `cmake` 进行构建，并使用 `ctest` 进行测试。 运行此命令时，条件将确保仅对特定平台运行适当的“安装依赖项”步骤。其他平台的其他步骤将被跳过。  现在，我们开始了解如何将GitHub Actions的简单片段组合到更复杂，功能更强大的工作流程中。 原文链接：https://www.edwardthomson.com/blog/github_actions_14_conditionals_with_a_matrix.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog) > > Follow me: [@qiwihui](https://github.com/qiwihui) > > Site: [QIWIHUI](https://qiwihui.com)
昨天我们看到，当你运行工作流程时，有许多可用数据。你可以在run步骤中使用这些数据，并将其与构建脚本，部署步骤或存储库自动化一起使用。但是你也可以在工作流本身中使用它。 利用这些数据的一种有用方法是[有条件地使用它来运行工作流步骤](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif)。 例如，你可能想在执行步骤之前检查工作流在其中运行的存储库的名称。如果你正在开发一个开源项目，这将很有帮助──因为fork你的存储库的人拥有[具有不同权限的令牌](https://qiwihui.com/qiwihui-blog-94/)，因此你可以跳过fork的发布步骤。 这使fork的存储库仍可以执行连续的集成构建，并确保在运行构建和测试通过时工作流成功，并且不会由于发布步骤上的权限问题而失败。 你可以设置一个条件，以确保你位于正确的存储库上并在CI构建中运行（来自push事件）。 现在，当此工作流在fork中运行时，将跳过“发布文档”步骤。  使用条件语句使你可以构建可在分支或分支之间共享的高级工作流，但其中某些步骤是针对特定触发器或环境量身定制的。 原文链接：https://www.edwardthomson.com/blog/github_actions_13_conditionals.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog) > > Follow me: [@qiwihui](https://github.com/qiwihui) > > Site: [QIWIHUI](https://qiwihui.com)
昨天我们看到GitHub为GitHub Actions工作流运行提供了一些信息，即 `GITHUB_TOKEN`。但这还不是全部。GitHub Actions还为你提供什么其他信息？ 其实很多！ GitHub Actions [设置了许多信息“上下文”](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#github-context)，其中包含有关你的工作流程运行的数据。例如，github 上下文包含信息，例如你的工作流在其中运行的存储库的名称 `github.repository`，启动工作流的用户 `github.actor`。你可以使用与 [处理矩阵](https://qiwihui.com/qiwihui-blog-85/) 和 [密码](https://qiwihui.com/qiwihui-blog-94/) 相同的双弯括号扩展语法来引用它们。  如果你想在上下文中查看GitHub Actions提供的所有信息，则可以实际使用方便的 `toJson` 函数来输出整个对象：  如果这样做，你会注意到GitHub上下文中有很多信息。特别是，`github.event` 对象本身就是一块巨大的json数据。它基本上包含与触发器相对应的 [Webhook 信息](https://developer.github.com/v3/activity/events/types/#pushevent)。 相同的事件信息已保存到磁盘上的 `github.event_path`。因此，你可以通过检查json blob来获取工作流程中的所有信息。幸运的是，非常方便的 [jq](https://stedolan.github.io/jq/) 工具已安装在...
如果你仅创建了一个或两个GitHub Actions工作流，则可能对如何起步不太关注，但是GitHub Actions团队关注如何起步，他们努力工作，以使你能尽可能轻松地开始使用Actions。 在创建新工作流程时，GitHub首先要考虑的是存储库中的代码类型。GitHub Actions使用成熟的[语言工具](https://github.com/github/linguist)来了解你的存储库包含哪种代码。这是为GitHub许多其他部分提供支持的工具，其中包括存储库主页上的语言统计栏。  对于这个拥有大量JavaScript的存储库，GitHub Actions将选择两个可能的工作流程──运行 `npm run build` 和 `npm test` 的Node.js CI/CD工作流程（这对应用程序有用），以及执行相同构建和测试运行的打包工作流程，然后将程序包发布到GitHub Packages中。  GitHub Actions不仅具有构建和测试项目的能力，还有工作流可以帮助你开始将应用程序部署到云中，无论是AWS，Azure还是Google Cloud。  而且，当然，尽管和语言学家一样好，它也不是完美的。许多人在同一存储库中混合了不同的项目，因此你还可以扩展整个启动程序工作流列表。  如果你想帮助改善入门工作流程──无论是对现有工作流程进行更改，还是添加全新的语言，都可以在[GitHub上](https://github.com/actions/starter-workflows)进行提交。 原文链接：https://www.edwardthomson.com/blog/github_actions_7_starter_workflows.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog)...
存储库中存在过时的issue可能是一个很大的危害。如果你有数年不打算解决的issue，那么就很难找到要关注的重要问题。你永远不会合并的pull request使你看起来好像在忽略该项目。项目中的所有这些杂项都增加了无形的认知负担。 在服务行业工作的任何人都会理解此问题。这就像一个厨师的 *场面调度连接* 的地方──在他们与他们的配料厨房的设置。 > 如果让你的现场发生故障，变脏和混乱，你会很快发现自己旋转到位并需要备份。我和一位厨师一起工作，他曾经在匆忙中走到排队的肮脏厨师的工作台旁，解释为什么违规的厨师落后了。他将手掌压在切菜板上，切菜板上撒满了胡椒粒，飞溅的酱汁，一些香菜，面包屑以及通常会漂浮在工作台上的漂浮物和抛弃物，如果不时常用潮湿的侧毛巾将其擦掉。“你看到了吗？” 他打了个招呼，抬起他的手掌，这样厨师就可以看到灰尘和碎屑粘在厨师的手掌上。“那就是你现在的脑袋。” > > Anthony Bourdain，厨房机密 当GitHub着手创建Actions平台时，他们希望构建一些对CI/CD工作流程非常有用的东西──构建项目，运行测试并部署它──但这也可以帮助你自动化项目中的常见任务。在这种情况下，请保持存储库的美观和整洁。 [启动程序工作流程](https://qiwihui.com/qiwihui-blog-90/)的底部是关闭陈旧issue和 pull request 的工作流程。  它会按计划触发运行，因此在每天UTC午夜： ```yml on: schedule: - cron: "0 0 * * *" ```...
本月到目前为止，我们已经研究了许多执行构建并运行一些测试的方案。这些都是很棒的工作流程──它们确保进入你的项目的pull request是高质量的，并且你的主分支是健康的。 但是，你通常想采取下一步并部署自己构建的内容。例如，你可能想构建一个容器，并在每次新的主分支合入新功能时将其上传到[GitHub Packages](https://github.com/features/packages)。这将确保你有一个可以运行并验证每个更改的容器。 为此，我们要触发向master的推送。（无论是从 `git push` 还是从合并pull request，只要[集成到master](https://www.edwardthomson.com/blog/github_actions_1_cicd_triggers.html)中，`push` 触发器都将运行。） 然后，我们将从docker登录到GitHub Packages。我们可以简单地使用GitHub Actions提供给我们的 `GITHUB_TOKEN`──令牌对我们存储库中的软件包具有发布权限。 然后，我们将构建容器，并使用包注册的名称对其进行标记（在本例中是 `docker.pkg.github.com` 其后为容器的名称 `ethomson/myrepo/app`），并为其指定版本号，即Unix时间。 最后，我们[将容器推送到GitHub Packages](https://gist.github.com/ethomson/60e664ef09051cea66dada5d53c62e6d)。 现在，我有一个简单的连续部署系统，该系统将始终使用包含来自master分支的最新版本的容器来更新GitHub Packages。 原文链接：https://www.edwardthomson.com/blog/github_actions_9_deploy_to_github_packages.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog) > > Follow...
前面我们看到可以限制[基于分支过滤器的](https://qiwihui.com/qiwihui-blog-84/)工作流运行。对于由 `push` 或 `pull_request` 触发的工作流，你可以对其进行限制，以使其仅在推送到特定分支或针对特定分支打开 pull request 时才触发。 你还可以限制这些工作流，以便仅在[推送特定路径](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onpushpull_requestpaths)时才触发它们。 如果你在提交某些东西时会运行一些自动化功能，这将非常有用。例如：在我的一个开源项目中，每次将提交合并到master分支中时，我们都会将文档发布到我们的网站上。但是，我们只想在文档实际更改时运行该工作流程。 在这种情况下，我们希望docs在master分支中目录中的任何内容更改时运行。我们可以使用[通配符](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)作为路径过滤器的一部分： 现在，我们有了一个工作流程，只要我们对文件docs夹中的文件进行新更改并将其合并到master分支中，就可以运行脚本 `publish_docs.sh`。 原文链接：https://www.edwardthomson.com/blog/github_actions_10_path_triggers.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog) > > Follow me: [@qiwihui](https://github.com/qiwihui) > > Site: [QIWIHUI](https://qiwihui.com)
因此，关于 GitHub Actions 的这些帖子甚至还不到一周，我已经写了很多有关 [矩阵工作流](https://qiwihui.com/qiwihui-blog-85/) 的文章。如你还没猜到，我是忠实粉丝。 😍 但是，如果你开始设置第一个矩阵工作流程，那么你需要注意：默认情况下，矩阵工作流程会[快速失败](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast)。这就是说：如果矩阵扩展中的一个作业失败，则其余作业将被取消。 这种行为通常非常有益：如果你正在运行 pull request 验证构建，而矩阵中的构建之一失败，则你可能根本不在乎其余的构建是否成功。任何失败都足以表明存在使你无法合并 PR 的问题。 但是，当你从头开始创建工作流时，可能需要迭代一下才能使其第一次正常工作。当作业失败是由于工作流设置中存在问题而不是代码本身存在问题时，关闭快速故障行为作为调试工具会很有帮助。 假设你有一个在 Linux 上运行良好的工作流程，并且希望使用矩阵将其扩展到可以在 macOS 和 Windows 上运行。对于简单的工作流程，这可能会正常工作。但是对于更复杂的事情，你可能需要先设置一些依赖项或安装一些工具，然后才能起作用。因此，很可能你的Linux上运行的工作流如果不做一些修改就无法在 macOS 或 Windows 上运行。 那么，当你第一次运行此新矩阵工作流时会发生什么？你的 Linux，macOS 和 Windows...
昨天我讨论了如何 [在GitHub Actions虚拟环境上安装工具和依赖项](https://qiwihui.com/qiwihui-blog-87/)。 但是，如果你需要更多控制权怎么办？ 或者，如果你根本不想在 Ubuntu 上运行，该怎么办？ 这是容器发光的地方。 通过创建一个包含所有需要的开发工具以及项目依赖项的容器，你不必操心在工作流运行开始时就对那些设置和安装步骤进行管理。 此外，你还将获得基于容器的开发的优势：你可以在用于CI构建的同一个容器中进行本地构建，因此你可以高度自信地确保 GitHub Actions 中的构建与构建时所看到的与本地匹配。 语法非常简单明了──我不需要自己运行任何 `docker pull` 或 `docker run` 命令。 GitHub Actions 为我解决了这个问题。要获取源代码并在 `node：current` 容器中运行测试，请执行以下操作： 当我运行此工作流时，GitHub Actions 将从 DockerHub 下载我指定的容器，启动它，然后直接在该容器中执行我指定的运行步骤。...
昨天我提到 GitHub Actions 提供了 [Linux，Windows 和 macOS 虚拟环境](https://qiwihui.com/qiwihui-blog-86/)，你可以在其中运行工作流。 但是这些环境上实际安装了什么？ 原来有[很多安装](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/software-installed-on-github-hosted-runners)。 团队试图通过许多不同的平台使我们的运行器（runners）保持最新状态。 因此，你会发现许多不同版本的Python，Ruby，.NET Core等。 但是──仅仅依靠这些各种各样的开发工具──他们不可能绝对安装所有东西。 有时你需要自己安装。而且由于你拥有一台完整的虚拟机，因此对于每项作业执行，你都可以在其上安装任何所需的软件。 例如，你可能要安装非常好的“[ninja](https://ninja-build.org/)”构建工具。 ### Linux Linux虚拟环境运行Ubuntu，因此你可以使用 [apt](https://en.wikipedia.org/wiki/APT_(Package_Manager)) 安装可能需要的任何其他工具。 默认情况下，你以非 root 用户身份运行，但是可以使用无密码 sudo。这样你就可以： ```yml run: sudo apt-get install...