[譯] 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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。