概述
Github在被微軟收購后,不忘初心,且更大力度的造福開發者們,推出了免費私有倉庫等大更新。近期又開放了packages和actions兩個大招,經筆者試用后感覺這兩個功能配合起來簡直無敵。
GitHub Packages 是一個和每一個代碼倉庫關聯的軟件包倉庫。通俗來說就是代碼倉庫中存放的是源碼,軟件包倉庫中存放的是編譯輸出后的可以被各個語言生態的依賴管理工具直接依賴的lib。類似的我們熟知的有maven中央倉庫和nmp倉庫。
GitHub Actions 是一個Github原生的持續集成和部署的工作流組件。通俗來說就是Github免費給你提供虛擬主機,由你編寫工作流腳本來進行源碼的檢出,編譯,測試,和發布。類似的我們可以想象成Github給每個倉庫都免費綁定了一個Jenkins服務,編寫pipeline腳本即可進行源碼的集成和發布。
Github Token
首先我們討論下Github Token,因為后續操作都需要用到這個Token.
Github Token是用戶登錄后生成的用戶憑證,類似JWT登錄令牌,令牌關聯了操作權限,用戶開發者授權給第三方服務進行倉庫管理或者開發者自己利用Github Api做一些極客操作。
操作入口:https://github.com/settings/tokens。
點擊生成Token后輸入描述性名稱,一般用來說明這個token是用來干嘛的,勾選這個token的權限。確認后會生成一個token字符串。這個token只會展示一次,退出頁面后就會消失,所以要謹慎保存。
如果token不慎泄露,可以在token列表對token進行失效操作。
Github Secrets 密文字典
密文字典用於將一些隱私的保密的配置如password,token等通過鍵值對的形式以密文保存在Github中,在一些需要的場景如Github Actions中,可以通過Github暴露的Api進行取用,避免了源碼公開導致的安全問題。
密文字典與各個代碼倉庫關聯,只能在當前代碼倉庫的上下文中使用,當前沒有全局的密文字典。
入口路徑為:倉庫 > Settings > Secrets
Github Packages 包倉庫
入口:
支持的包類型:
包客戶端 | 語言 | 包格式 | 描述 | 倉庫地址 |
---|---|---|---|---|
npm |
JavaScript | package.json |
Node package manager | https://npm.pkg.github.com |
gem |
Ruby | Gemfile |
RubyGems package manager | https://USERNAME:TOKEN@rubygems.pkg.github.com/OWNER/ |
mvn |
Java | pom.xml |
Apache Maven project management and comprehension tool | https://maven.pkg.github.com/OWNER/REPOSITORY |
gradle |
Java | build.gradle 或 build.gradle.kts |
Gradle build automation tool for Java | https://maven.pkg.github.com/OWNER/REPOSITORY |
docker |
N/A | Dockerfile |
Docker container management platform | |
dotnet CLI |
.NET | nupkg |
NuGet package management for .NET |
各類型賬戶的限制(自用完全夠用了):
產品 | 存儲 | 每月流量 |
---|---|---|
GitHub Free | 500MB | 1GB |
GitHub Pro | 1GB | 5GB |
GitHub Team | 2GB | 10GB |
GitHub Enterprise Cloud | 50GB | 100GB |
當前Packages支持常見的Docker,Java,Nodejs等生態。默認每個Github倉庫都會關聯一個包倉庫。每個包倉庫為一個包命名空間,因為每個包倉庫地址都關聯了代碼倉庫的id擁有者的id和。如一個Docker鏡像名為Test:latest
可以發布到多個Github包倉庫且不會互相覆蓋(Npm包的命名規則將代碼倉庫id和用戶id放在了包名上,沒有放在包倉庫地址上)。
雖然公開代碼倉庫的包倉庫界面是公開可讀的,但是包的發布和下載需要認證。需要使用Github Token。下載需要認證目前被吐槽的比較狠,社區已經在討論這個issue,后續可能會允許免密下載。
下面以Docker為例講解用法。
1、首先我們要進行登陸:
$ docker login -u USERNAME -p TOKEN docker.pkg.github.com
2、登錄后我們將指定鏡像重命名為Github Packages規定的Docker鏡像名:
$ docker tag IMAGE_ID docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
注意:鏡像名格式為docker倉庫域名+倉庫擁有者id+倉庫名+鏡像名+版本號
3、發布鏡像
$ docker push docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
回到倉庫頁面,進入Packages,可以看到發布的包:
點擊包名進入詳情:
Github Actions 持續集成工作流
1、Github免費提供了虛擬主機,用來提供持續集成的運行環境。處於安全性考慮也可以使用自己的服務器資源執行構建任務,詳見:Hosting your own runners
主機規格:
- 2-core CPU
- 7 GB of RAM memory
- 14 GB of SSD disk space
當前可選的運行環境有:
Environment | YAML Label | Included Software |
---|---|---|
Ubuntu 18.04 | ubuntu-latest or ubuntu-18.04 |
ubuntu-18.04 |
Ubuntu 16.04 | ubuntu-16.04 |
ubuntu-16.04 |
macOS 10.15 | macos-latest or macos-10.15 |
macOS-10.15 |
Windows Server 2019 | windows-latest or windows-2019 |
windows-2019 |
Windows Server 2016 | windows-2016 |
windows-2016 |
各個運行環境中預裝了常用的工具和各個語言生態的工具鏈,Ubuntu環境預裝的軟件列表:列表
以Java生態為例,Git,Docker,JDK,Maven已經預裝:
2、使用方式:
Actions使用YAML文件來編寫聲明式工作流。
在代碼倉庫根目錄新建 github/workflows
目錄,目錄內的所有.yml
文件都會被識別為一個持續集成工作流。
腳本語法詳見阮一峰的博客,簡介如下:
工作流使用聲明式語法,指定要干嘛,不需要說明怎么干,使用這種策略腳本清晰可讀,但是表達能力較弱。
指定目錄下每個yml文件會被自動識別為一個工作流,每個工作流由有自己的名稱,和觸發工作流的事件。事件主要分為:
- git操作相關的事件如push,pull request等。
- cron表達式
一個工作流包含多個job,需要指定運行環境。job之間是異步執行的,可以通過needs顯式指定依賴來干預job執行次序,由於job在不同主機上執行,分屬不同的文件系統,各個job產生的構建中間產物無法共用,一般通過將構建產物發布到artifacts來進行銜接。
一個job可以包含多個step,同一個job中的setp是同步執行的,各個步驟的構建產物都在當前job使用的主機上。
由於步驟重合度高,如maven編譯,docker構建,docker發布等,Github使用應用市場來匯總開發者開源的構建步驟腳本,用於重用。Github自己也開發了一些基礎功能腳本如 actions/checkout
。
可以通過在步驟中使用uses
命令+actions名稱@版本來引用功能,節約成本和可讀性。
Token,密碼等隱私變量可以通過暴露的Secrets對象利用插值語法來引用。
3、為了豐富工作流腳本的表達能力,Github在腳本編譯執行上下文中暴露了一些Github變量和環境變量,用於開發者使用。
Github變量如下:
Context name | Type | Description |
---|---|---|
github |
object |
Information about the workflow run. For more information, see github context. |
env |
object |
Contains environment variables set in a workflow, job, or step. For more information, see env context . |
job |
object |
Information about the currently executing job. For more information, see job context. |
steps |
object |
Information about the steps that have been run in this job. For more information, see steps context. |
runner |
object |
Information about the runner that is running the current job. For more information, see runner context. |
secrets |
object |
Enables access to secrets set in a repository. For more information about secrets, see "Creating and using encrypted secrets." |
strategy |
object |
Enables access to the configured strategy parameters and information about the current job. Strategy parameters include fail-fast , job-index , job-total , and max-parallel . |
matrix |
object |
Enables access to the matrix parameters you configured for the current job. For example, if you configure a matrix build with the os and node versions, the matrix context object includes the os and node versions of the current job. |
環境變量如下:
Environment variable | Description |
---|---|
HOME |
The path to the GitHub home directory used to store user data. For example, /github/home . |
GITHUB_WORKFLOW |
The name of the workflow. |
GITHUB_RUN_ID |
A unique number for each run within a repository. This number does not change if you re-run the workflow run. |
GITHUB_RUN_NUMBER |
A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run. |
GITHUB_ACTION |
The unique identifier (id ) of the action. |
GITHUB_ACTIONS |
Always set to true when GitHub Actions is running the workflow. You can use this variable to differentiate when tests are being run locally or by GitHub Actions. |
GITHUB_ACTOR |
The name of the person or app that initiated the workflow. For example, octocat . |
GITHUB_REPOSITORY |
The owner and repository name. For example, octocat/Hello-World . |
GITHUB_EVENT_NAME |
The name of the webhook event that triggered the workflow. |
GITHUB_EVENT_PATH |
The path of the file with the complete webhook event payload. For example, /github/workflow/event.json . |
GITHUB_WORKSPACE |
The GitHub workspace directory path. The workspace directory contains a subdirectory with a copy of your repository if your workflow uses the actions/checkout action. If you don't use the actions/checkout action, the directory will be empty. For example, /home/runner/work/my-repo-name/my-repo-name . |
GITHUB_SHA |
The commit SHA that triggered the workflow. For example, ffac537e6cbbf934b08745a378932722df287a53 . |
GITHUB_REF |
The branch or tag ref that triggered the workflow. For example, refs/heads/feature-branch-1 . If neither a branch or tag is available for the event type, the variable will not exist. |
GITHUB_HEAD_REF |
Only set for forked repositories. The branch of the head repository. |
GITHUB_BASE_REF |
Only set for forked repositories. The branch of the base repository. |
總結
自從Github抱上了巨硬這條大腿以后,瘋狂向開發者拋出大利好。畢竟背后有巨硬財大氣粗,而且巨硬靠着企業業務賺錢也不指着向開發者個人收費。
結合Github Actions和Github Packages,可以完成一整個CI閉環,比如代碼Push到Github上的某個分支,觸發Action,構建Docker鏡像push到Packages,調用Webhook觸發阿里雲服務器pull image部署。對於個人寫一些小的開源項目完美夠用,節約了在阿里雲服務器搭建Jenkins等CI服務的資源。真香~~~
考慮到Github Actions提供的虛擬主機性能不錯(比我買的阿里雲主機好多了...)有公網IP可以訪問外網,其實還可以玩點別的花活,比如搶火車票?爬網頁?刷評論?發動你的腦瓜殼吧~