[譯] GitHub Actions 介紹，瞭解一下？

子非發表於2018-11-06
Github

有一種常見的情況：你建立了一個網站並且已經準備執行了。這一切都在 GitHub 上。但是你還沒真正完成。你需要準備部署。你需要準備一個處理程式來為你執行測試，你不用總是手動執行命令。理想情況下，每一次你推送到 master 分支，所有東西都會在某個地方為你自動執行：測試，部署……

以前，只有很少的選項可以幫助解決這個問題。你可能需要把其他服務集中，設定，並和 GitHub 整合。你也可以寫 post-commit hooks，這也會有幫助。

但是現在，GitHub Actions 已經到來。

[譯] 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 版站點的截圖，其中有一個巨大的藍色按鈕來點選加入 beta 測試。

GitHub Actions beta 版站點。

現在我們來建立一個倉庫。我使用一個小的 Node.js 演示站點建了一個小型演示倉庫。我可以發現在我的倉庫上已經有一個新選項卡，叫做 Actions：

在演示倉庫的截圖中顯示選單中的 Actions 選項卡

如果我點選 Actions 選項卡，螢幕會顯示：

螢幕顯示

我點選“Create a New Workflow”，然後我能看到下面的介面。這告訴我一些東西。首先，我建立了一個叫 .github 的隱藏資料夾，在它裡面，我建立了一個叫 main.workflow 的隱藏檔案。如果你要從 scratch（我們將詳細講解）建立工作流，你需要執行相同的操作。

新工作流

現在，我們能看到在這個 GUI 中我們啟動了一個新的工作流。如果從我們的第一個 action 畫一條線，會出現一個擁有大量選項的邊側欄。

顯示邊側欄中所有 action 選項

這裡有很多關於 npm、Filters、Google Cloud、Azure、Zeit、AWS、Docker Tags、Docker Registry 和 Heroku 的 action。如前所述，你沒有任何關於這些選項的限制 —— 它能夠做的非常多！

我在 Azure 工作，所以我將以此為例，但是每一個 action 都提供給你相同選項，我們可以一起使用。

在邊側欄顯示 Azure 選項

在頂部，你可以看到“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 都可以重新部署啦 ?

工作流執行成功

Hello Word App 的截圖

改變遊戲規則

GitHub Actions 並不僅僅只是關於網站，儘管你可以看到它們對它們有多麼方便。這是一種全新的思考方式，關於我們怎樣處理基礎設施，事件甚至託管的方式。在這個模型中需要考慮 Docker。

通常，當你建立 Dockerfile 時，你必須編寫 Dockerfile，使用 Docker 建立映象，然後將映像推送到某處，以便託管供其他人下載。在這個範例中，你可以將它指向一個包含現有 Docker 檔案的 git 倉庫，或者直接託管在 Docker 上的東西。

你也不需要在任何地方託管映象，因為 GitHub 會為你即時構建。這使得 GitHub 生態系統中的所有內容都保持開放，這對於開源來說是巨大的，並且可以更容易地 fork 和共享。你還可以將 Dockerfile 直接放在你的操作中，這意味著你不必為這些 Dockerfiles 維護單獨的倉庫。

總而言之，這非常令人興奮。部分原因在於靈活性：一方面，你可以選擇使用大量抽象並使用 GUI 和現有操作建立所需的工作流，另一方面，你可以在容器內自己編寫程式碼，構建和微調任何想要的內容，甚至將多個可重用的自定義 action 連結在一起。全部在一個地方託管你的程式碼。

如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。

相關文章