[译] GitHub Actions 介绍，了解一下？

• 原文地址：Introducing GitHub Actions
• 原文做者：SARAH DRASNER
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：子非
• 校对者：Raoul1996, calpa

有一种常见的状况：你建立了一个网站而且已经准备运行了。这一切都在 GitHub 上。可是你还没真正完成。你须要准备部署。你须要准备一个处理程序来为你运行测试，你不用老是手动运行命令。理想状况下，每一次你推送到 master 分支，全部东西都会在某个地方为你自动运行：测试，部署……

之前，只有不多的选项能够帮助解决这个问题。你可能须要把其余服务集中，设置，并和 GitHub 整合。你也能够写 post-commit hooks，这也会有帮助。

可是如今，GitHub Actions 已经到来。

Actions 是一小段代码片断，能够运行不少 GitHub 事件，最广泛的是推送到 master 分支。但它并不是仅限于此。它们都已经直接和 GitHub 整合，这意味着你不在须要中间服务或者须要你本身来写方案。而且它们已经有不少选项可供你选择。例如，你能够发布到 NPM 而且部署到各类云服务，举一些例子（Azure，AWS，Google Cloud，Zeit……凡是你说得出的）。

可是 actions 并不只仅只是部署和发布。 这就是它们酷炫的地方。它们都是容器，绝不夸张地说你能够作任何事情 —— 有着无尽的可能性！你能够用它们压缩合并 CSS 和 JavaScript，在人们在你的项目仓库里在你的仓库建立 issue 的时候向你发送信息，以及更多……没有任何限制。

你也能够不须要本身来配置或建立容器。Actions 容许你指向别的项目仓库，一个已存在的 Dockerfile，或者路径，操做将相应地运行。对于开源可能性和生态系统而言，这是一种全新的蠕虫病毒。

创建你的第一个 action

有两种方法创建 action：经过流程 GUI 或者手动写提交文件。咱们将以 GUI 开始，由于它简单易懂，而后学习手写方式，由于它能提供最大化的控制。

首先，咱们经过此处蓝色的大按钮登陆 beta 版。进入 beta 版可能会花费一点点时间，稍等一下。

GitHub Actions beta 版站点。

如今咱们来建立一个仓库。我使用一个小的 Node.js 演示站点建了一个小型演示仓库。我能够发如今个人仓库上已经有一个新选项卡，叫作 Actions：

若是我点击 Actions 选项卡，屏幕会显示：

我点击“Create a New Workflow”，而后我能看到下面的界面。这告诉我一些东西。首先，我建立了一个叫 .github 的隐藏文件夹，在它里面，我建立了一个叫 main.workflow 的隐藏文件。若是你要从 scratch（咱们将详细讲解）建立工做流，你须要执行相同的操做。

如今，咱们能看到在这个 GUI 中咱们启动了一个新的工做流。若是从咱们的第一个 action 画一条线，会出现一个拥有大量选项的边侧栏。

这里有不少关于 npm、Filters、Google Cloud、Azure、Zeit、AWS、Docker Tags、Docker Registry 和 Heroku 的 action。如前所述，你没有任何关于这些选项的限制 —— 它可以作的很是多！

我在 Azure 工做，因此我将以此为例，可是每个 action 都提供给你相同选项，咱们能够一块儿使用。

在顶部，你能够看到“GitHub Action for Azure”标题，其中包含“View source”连接。这将直接带你到用于运行此操做的仓库。这很是好，由于你还能够提交拉取请求以改进其中任何一项，而且能够根据 Actions 面板中的“uses”选项灵活地更改你正在使用的 action。

如下是咱们提供的选项的简要说明：

• Label：这是 Action 的名称，正如你所假设的那样。此名称由 resolves 数组中的工做流引用 —— 这就是在它们之间建立链接的缘由。这篇文章是在 GUI 中为你抽象出来的，但你会在下一节中看到，若是你在代码中工做，你须要保持引用相同才能进行连接工做。
• Runs：容许你覆盖入口点。这很好，由于若是你想 git 在容器中运行，能够作到！
• Args：这是你所指望的 —— 它容许你将参数传递给容器。
• secrets 和 env：这些都是很是重要的，由于这是你将如何使用密码，保护数据，而无需直接提交他们到仓库。若是你正在使用须要令牌来部署的东西，你可能会在这里使用 secret 来传递它。

其中许多操做都有自述文件，能够告诉您须要什么。“secrets”和“env”的设置一般以下所示：

action "deploy" {
  uses = ...
  secrets = [
    "THIS_IS_WHAT_YOU_NEED_TO_NAME_THE_SECRET",
  ]
}
复制代码

您还能够在 GUI 中将多个 action 串联起来。很容易让 action 顺序执行或并行执行。这意味着只需在界面中将东西连接在一块儿就能够很好地运行异步代码。

用代码写 action

若是这里显示的并无咱们须要的怎么办？幸运的是写 action 其实很是有趣！我写过一个 action 来部署 Node.js 的 Web 应用到 Azure，由于它容许我在每次推送到仓库的主分支时随时部署。这个超级有趣，由于我如今能够复用它到个人其它 Web 应用。

建立应用服务帐户

若是你要使用其它服务，这部分会发生变化，可是你须要在你要在你使用的地方建立一个已存在的服务来部署。

首先你须要获取你的免费 Azure 帐户。我喜欢用 Azure CLI，若是你没有安装过，你能够运行：

brew update && brew install azure-cli
复制代码

而后，咱们运行下面代码来登陆：

az login
复制代码

如今，咱们会建立 Service Principle，经过运行：

az ad sp create-for-rbac --name ServicePrincipalName --password PASSWORD
复制代码

它会输出以下内容，会在建立咱们的 action 时用到：

{
  "appId": "APP_ID",
  "displayName": "ServicePrincipalName",
  "name": "http://ServicePrincipalName",
  "password": ...,
  "tenant": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}
复制代码

action 里面有什么？

这里有一个基本的流程示例和一个 action，你能够看到它的架构：

workflow "Name of Workflow" {
  on = "push"
  resolves = ["deploy"]
}

action "deploy" {
  uses = "actions/someaction"
  secrets = [
    "TOKEN",
  ]
}
复制代码

能够看到咱们启动了流程，并明确咱们想它在 on push（on = "push"）运行。还有不少其它你能够用的选项，这里是完整的清单列表。

下方的 resolves 行 resolves = ["deploy"] 是一个 action 数组，它会串联随后的工做流。不用指定顺序，只是一个彻底列表。你能够看到咱们调用“deploy”后面的 action —— 只须要匹配这些字符串，这就是它们之间如何引用的。

下面，咱们看一看 action 部分。第一行 uses 十分有趣：马上你可使用咱们以前讨论的任何预约义 action（这是彻底清单）。但你也可使用其它人的仓库，甚至是托管在 Docker 站点的文件。例如，若是咱们想在容器中执行 git，让咱们使用这个。我能够这样作 uses = "docker://alpine/git:latest"。（感谢 Matt Colyer 为我指出 URL 的正确方法）

咱们可能须要在这里定义一些机密的配置或环境变量，而且这样使用它们：

action "Deploy Webapp" {
  uses = ...
  args = "run some code here and use a $ENV_VARIABLE_NAME"
  secrets = ["SECRET_NAME"]
  env = {
    ENV_VARIABLE_NAME = "myEnvVariable"
  }
}
复制代码

建立一个自定义 action

自定义 action 会采用咱们运行部署 Web App 到 Azure 常常用的命令，并把它们写成以只传几个值的方式，这样 action 就会为咱们所有执行。文件看起来要比你在 GUI 上建立的第一个基础 Azure action 更复杂而且是创建在它之上的。

在 entrypoint.sh：

#!/bin/sh 
set -e

echo "Login"
az login --service-principal --username "${SERVICE_PRINCIPAL}" --password "${SERVICE_PASS}" --tenant "${TENANT_ID}"

echo "Creating resource group ${APPID}-group"
az group create -n ${APPID}-group -l westcentralus

echo "Creating app service plan ${APPID}-plan"
az appservice plan create -g ${APPID}-group -n ${APPID}-plan --sku FREE

echo "Creating webapp ${APPID}"
az webapp create -g ${APPID}-group -p ${APPID}-plan -n ${APPID} --deployment-local-git

echo "Getting username/password for deployment"
DEPLOYUSER=`az webapp deployment list-publishing-profiles -n ${APPID} -g ${APPID}-group --query '[0].userName' -o tsv`
DEPLOYPASS=`az webapp deployment list-publishing-profiles -n ${APPID} -g ${APPID}-group --query '[0].userPWD' -o tsv`

git remote add azure https://${DEPLOYUSER}:${DEPLOYPASS}@${APPID}.scm.azurewebsites.net/${APPID}.git

git push azure master
复制代码

这个文件有几点有趣的东西要注意：

• shell 脚本中的 set -e 确保若是有任何事情发生异常，文件其他部分则不会运行。
• 随后的“Getting username/password”行看起来有点棘手 —— 实际上他们作的是从 Azure 的发布文档 中抽取用户名和密码。咱们能够在随后要使用 remote add 的行中使用它。
• 你也许会注意到有些行咱们传入了 -o tsv，这是格式化代码，因此咱们能够把它直接传进环境变量，如 tsv 脚本剔除多余的头部信息等等。

如今咱们开始着手 main.workflow 文件！

workflow "New workflow" {
  on = "push"
  resolves = ["Deploy to Azure"]
}

action "Deploy to Azure" {
  uses = "./.github/azdeploy"
  secrets = ["SERVICE_PASS"]
  env = {
    SERVICE_PRINCIPAL="http://sdrasApp",
    TENANT_ID="72f988bf-86f1-41af-91ab-2d7cd011db47",
    APPID="sdrasMoonshine"
  }
}
复制代码

这段流程代码对你来讲应该很熟悉 —— 它在 on push 时启动而且执行叫“Deploy to Azure”的 action。

uses 指向内部的目录，在这个目录咱们存放其余文件。咱们须要添加一个秘钥，来让咱们在 App 里存放密码。咱们把这个叫服务密码，而且咱们会在设置里添加配置它：

最终，咱们有了须要运行命令的全部环境变量。咱们能够从以前建立 App 服务帐户得到它们。先前的 tenant 变成了 TENANT_ID，name 变成了 SERVICE_PRINCIPAL，而且 APPID 由你来命名 :)

如今你也可使用这个 action 工具！全部的代码在这个仓库中开源。只要记住因为咱们手动建立 main.workflow，你将必须同时手动编辑 main.workflow 文件里的环境变量 —— 一旦你中止使用 GUI，它的工做方式将和以前再也不同样。

这里你能够看到项目部署的很是好而且状态良好，每当推送到 master 时咱们的 “Hello World” App 均可以从新部署啦 🎉

改变游戏规则

GitHub Actions 并不只仅只是关于网站，尽管你能够看到它们对它们有多么方便。这是一种全新的思考方式，关于咱们怎样处理基础设施，事件甚至托管的方式。在这个模型中须要考虑 Docker。

一般，当你建立 Dockerfile 时，你必须编写 Dockerfile，使用 Docker 建立镜像，而后将映像推送到某处，以便托管供其余人下载。在这个范例中，你能够将它指向一个包含现有 Docker 文件的 git 仓库，或者直接托管在 Docker 上的东西。

你也不须要在任何地方托管镜像，由于 GitHub 会为你即时构建。这使得 GitHub 生态系统中的全部内容都保持开放，这对于开源来讲是巨大的，而且能够更容易地 fork 和共享。你还能够将 Dockerfile 直接放在你的操做中，这意味着你没必要为这些 Dockerfiles 维护单独的仓库。

总而言之，这很是使人兴奋。部分缘由在于灵活性：一方面，你能够选择使用大量抽象并使用 GUI 和现有操做建立所需的工做流，另外一方面，你能够在容器内本身编写代码，构建和微调任何想要的内容，甚至将多个可重用的自定义 action 连接在一块儿。所有在一个地方托管你的代码。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。