前言

最近在學(xué)習(xí) Angular，一些基礎(chǔ)的語法也學(xué)習(xí)的差不多了，就在 github 上新建了一個代碼倉庫，準(zhǔn)備用 ng-zorro 搭個后臺應(yīng)用的模板，方便自己以后寫些小東西時可以直接使用。前端項目，最主要的還是能夠?qū)嶋H看到，因此考慮找個地方部署，因為自己的博客是部署到 github page 上的，并且這個項目也只是一個靜態(tài)網(wǎng)站，所以這里同樣選擇使用 github page

同時，考慮到發(fā)布項目時，雖然使用 github page 已經(jīng)幫我們省略了拷貝文件到服務(wù)器上這一步，但是還是需要自己手動的敲命令來完成項目的發(fā)布，因為發(fā)布的流程很單一，所以這里選擇通過 github action 這個自動化工具來實現(xiàn)程序的自動化部署

代碼倉庫地址：ingos-admin

預(yù)覽地址：https://yuiter.com/ingos-admin

Step by Step

2.1、手動部署

示例的 Angular 應(yīng)用，你可以通過 Angular CLI 直接生成，如有需要，可以點擊此鏈接進(jìn)行跳轉(zhuǎn)查看（電梯直達(dá)），這里就不演示創(chuàng)建的過程了

按照正常的前端項目發(fā)布流程，當(dāng)我們需要發(fā)布時，需要使用 npm 命令來完成項目的打包。整個項目中所涉及的 npm 命令，我們可以通過查閱項目的 package.json 文件中的 scripts 節(jié)點進(jìn)行查看

這里通過 Angular CLI 創(chuàng)建的項目可以通過 ng build 命令來完成項目的打包發(fā)布

當(dāng) build 命令執(zhí)行完成后，項目根路徑下 dist 文件夾中以項目名稱命名的文件夾就是我們需要部署的文件。此時，如果是部署到自己的服務(wù)器上，只需要把這個文件夾拷貝到服務(wù)器上，通過 nginx 之類的服務(wù)器指向文件所在路徑即可

同樣的，當(dāng)我們想要部署到 github page 時，我們也只需要將文件提交到 github 代碼倉庫中即可，之后 github 會自動完成應(yīng)用的部署工作

因為 git 默認(rèn)是會忽略編譯生成的 dist 文件夾的，此時，想要把編譯生成的文件推送到遠(yuǎn)程倉庫，你需要修改 .gitignore 文件，或是通過 subtree 的形式，將 dist 文件夾作為一個分支推送到遠(yuǎn)程服務(wù)器

# 創(chuàng)建并切換到 gh-pages 分支
git checkout -b gh-pages
# 將 dist 文件夾下的文件添加到 gh-pages 分支
git add -f dist
# 提交到本地分支
git commit -m 'created gh-pages'
# 推送到遠(yuǎn)程分支
git subtree push --prefix dist origin gh-pages

當(dāng)然，這樣還是顯得有些麻煩，對于 angular 應(yīng)用來說，我們完全可以使用社區(qū)提供的 angular-cli-ghpages 插件來簡化這個操作

首先我們需要通過 npm 將插件安裝到需要部署的程序中

ng add angular-cli-ghpages

安裝完成之后，我們就可以通過 ng deploy 命令來完成部署，插件會自動把打包生成的文件發(fā)布到 github 上，并創(chuàng)建一個 gh-pages 分支作為 github page 顯示的站點

ng deploy --base-href=/ingos-admin/

在之前學(xué)習(xí) angular 中路由時有提到，在 angular 應(yīng)用中，框架會將 index.html 文件中的 base 標(biāo)簽的 href 屬性值配置為組件、模板、模塊文件以及其它一些靜態(tài)文件的基礎(chǔ)路徑地址。而當(dāng)我們將程序部署到 github page 時，實際對應(yīng)的網(wǎng)站地址是 https://<username>.github.io/<repositoryname>，因此，這里如果不指定 href 的話，程序會在根路徑下去尋找站點相關(guān)的靜態(tài)文件，毫無疑問，最終是無法找到的，所以這里我們需要調(diào)整 href 屬性值 為我們的倉儲名稱

可以看到，在打包生成的 index.html 文件中，插件已經(jīng)幫我們修改了 base 標(biāo)簽的 href 地址。以后當(dāng)我們需要更新網(wǎng)站時，再使用上面的命令即可發(fā)布到 github page 上

因為每次執(zhí)行 ng deploy 命令時都需要在命令中添加 base-href 參數(shù)，所以這里我們可以在 package.json 文件中添加一個 script，這樣當(dāng)后面我們需要發(fā)布時，直接執(zhí)行自定義的 ng deploy 命令即可

{
 "name": "ingos-admin",
 "version": "1.0.0",
 "scripts": {
 "ng": "ng",
 "start": "ng serve",
 "build": "ng build",
 "deploy": "ng deploy --base-href=/ingos-admin/",
 "test": "ng test",
 "lint": "ng lint",
 "e2e": "ng e2e"
 }
}

2.2、自動部署

在上面的操作中雖然實現(xiàn)了將程序部署到 github page，但是還是需要我們手動的通過 npm 命令來完成部署，接下來就進(jìn)行改造，通過 github actions 來實現(xiàn)自動部署

github actions 與其它的各種自動化工具相似，允許我們通過指定特定的 git 事件來觸發(fā)我們的自動化任務(wù)，例如這里我需要在推送代碼到服務(wù)器的 master 分支時自動觸發(fā)程序的發(fā)布事件

你可以在代碼倉庫的 Actions tab 頁面新增一個 workflow，也可以直接在本地代碼根路徑中新建一個 .github/workflows 文件夾來存放相關(guān)的腳本，因為 github actions 的執(zhí)行腳本采用的是 yaml 格式，所以這里對于代碼格式有著嚴(yán)格的要求，而每一個 yaml 文件則是一個單獨的 workflow

這里我通過直接調(diào)整 github 默認(rèn)的 workflow 文件來實現(xiàn)自動化部署功能，整個 yaml 文件包含了如下的三個部分

• name：當(dāng)前 workflow 配置的名稱
• on：任務(wù)觸發(fā)時機，這里是在向 github 上的 master 分支提交代碼以及提交 PR 時進(jìn)行觸發(fā)
• jobs：需要觸發(fā)的任務(wù)信息，一個 workflow 可以包含多個的 job，這里只有一個名為 build 的 job

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
 push:
 branches: [master]
 pull_request:
 branches: [master]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
 # This workflow contains a single job called "build"
 build:
 # The type of runner that the job will run on
 runs-on: ubuntu-latest

 # Steps represent a sequence of tasks that will be executed as part of the job
 steps:
 # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
 - uses: actions/checkout@v2

 # Runs a single command using the runners shell
 - name: Run a one-line script
  run: echo Hello, world!

 # Runs a set of commands using the runners shell
 - name: Run a multi-line script
  run: |
  echo Add other actions to build,
  echo test, and deploy your project.

一個 workflow 文件中最重要的就是包含的 jobs，它表明了當(dāng)前 workflow 所能實現(xiàn)的功能，一個 job 任務(wù)主要包含了如下的屬性

• runs-on：當(dāng)前 job 需要運行在的系統(tǒng)環(huán)境
• steps：實現(xiàn)一個 job 需要執(zhí)行的各個步驟
• env：當(dāng)前 job 執(zhí)行時需要的各種環(huán)境變量
• needs：當(dāng)我們定義多個 job 時，默認(rèn)是并行執(zhí)行的，但是存在 job2 需要等 job1 執(zhí)行完成后才可以執(zhí)行的情況，這時，我們就可以在 needs 屬性中指定 job2 依賴于 job1，從而確保整個 workflow 的正確執(zhí)行

在 steps 節(jié)點中，定義了當(dāng)前 job 需要執(zhí)行的各個步驟，step 分為兩種，一種是我們使用 users 屬性來直接引用別人已經(jīng)發(fā)布的 action，例如這里通過引用 github 官方的 actions/checkout@v2 在宿主機中執(zhí)行 git checkout 命令來拉取代碼；另一種，則是我們通過 run 屬性來手動編寫腳本

對于我們想要的實現(xiàn)的功能，其實只包含了如下的四步：拉取代碼 =》安裝 node.js 環(huán)境 =》還原依賴 =》部署發(fā)布

對于拉取代碼以及安裝 node.js 環(huán)境，我們可以使用 github 官方的 action 來簡化我們的腳本，因為我們在每次構(gòu)建時都需要執(zhí)行 npm install 命令來還原項目所需的各種依賴，因此這里在執(zhí)行 install 命令之前，我們可以通過官方的 actions/cache@v2 來緩存項目依賴，以加快構(gòu)建的過程

這里在還原依賴時，使用到了 npm ci 而不是 npm install，從命令的名稱就可以看出，ci 主要是在各種自動化環(huán)境構(gòu)建時使用，通過讀取 package-lock.json 文件中所包含的具體的依賴版本信息來加快還原過程

steps:
 # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
 - uses: actions/checkout@v2

 # Install node js
 - name: Setup Node.js environment
 uses: actions/setup-node@v1
 with:
  node-version: 12.x

 # Cache node modules
 - name: Cache node modules
 uses: actions/cache@v2
 env:
  cache-name: cache-node-modules
 with:
  # npm cache files are stored in `~/.npm` on Linux/macOS
  path: ~/.npm
  key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
  restore-keys: |
  ${{ runner.os }}-build-${{ env.cache-name }}-
  ${{ runner.os }}-build-
  ${{ runner.os }}-

 # Install required dependencies to build app
 - name: Install dependencies
 run: npm ci

當(dāng)還原完成之后，就可以執(zhí)行 package.json 文件中的 deploy 命令了，這里需要注意，因為在 action 中執(zhí)行的命令更多的都是只讀權(quán)限，所以為了能夠有足夠的權(quán)限執(zhí)行發(fā)布操作，我們需要在執(zhí)行時在環(huán)境變量中附加上 GITHUB_TOKEN 變量

steps:
 # Use angular-cli-ghpages to deploy app
 - name: Deploy to github pages
 env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 run: npm run deploy

secrets.GITHUB_TOKEN 因為是 github 默認(rèn)創(chuàng)建的，因此我們可以在 workflow 中直接使用，而對于一些另外需要授權(quán)的服務(wù)，直接將密碼寫在 yaml 文件中會不安全，這時你就可以在代碼倉庫的 settings tab 下通過設(shè)置 secrets 密鑰信息，然后就可以通過變量的方式在 workflow 中直接使用

當(dāng)我們添加了環(huán)境變量之后，還需要對我們的實際執(zhí)行的 npm 命令腳本進(jìn)行一個調(diào)整

在本地執(zhí)行發(fā)布命令時，本地的 git 配置中已經(jīng)包含了相關(guān)的賬戶信息，而當(dāng)在 workflow 中執(zhí)行時因為處于一個匿名的狀態(tài)，angular-cli-ghpages 沒辦法知道具體的執(zhí)行人是誰，因此，我們需要在 ng deploy 命令中添加上 git 賬戶相關(guān)的配置參數(shù)

{
 "name": "ingos-admin",
 "version": "1.0.0",
 "scripts": {
 "deploy": "ng deploy --no-silent --base-href=/ingos-admin/ --name='賬戶名' --email='密碼'",
 }
}

至此，完整的 workflow 腳本如下，當(dāng)我們將本地代碼推送到 github 倉庫時，就會自動完成程序的發(fā)布部署

# This is a basic workflow to deploy angular app into github pages
name: Deploy Github Pages

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
 push:
 branches: [master]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
 build:
 # The type of runner that the job will run on
 runs-on: ubuntu-latest

 # Steps represent a sequence of tasks that will be executed as part of the job
 steps:
  # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
  - uses: actions/checkout@v2

  # Install node js
  - name: Setup Node.js environment
  uses: actions/setup-node@v1
  with:
   node-version: 12.x

  # Cache node modules
  - name: Cache node modules
  uses: actions/cache@v2
  env:
   cache-name: cache-node-modules
  with:
   # npm cache files are stored in `~/.npm` on Linux/macOS
   path: ~/.npm
   key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
   restore-keys: |
   ${{ runner.os }}-build-${{ env.cache-name }}-
   ${{ runner.os }}-build-
   ${{ runner.os }}-

  # Install required dependencies to build app
  - name: Install dependencies
  run: npm ci

  # Use angular-cli-ghpages to deploy app
  - name: Deploy to github pages
  env:
   GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: npm run deploy

這里需要需要注意，因為代碼中包含了 workflow 文件，可能在推送到 github 時遇到如下的錯誤，此時需要我們對 access token 進(jìn)行重新的設(shè)置

打開 GitHub Personal Access Tokens 頁面，點擊右側(cè)的 Generate new token 按鈕，選擇新建一個 token 信息，在編輯權(quán)限時確保 workflow 有被勾選上，

復(fù)制生成的 token 信息，打開電腦的憑據(jù)管理器，在 Windows 憑據(jù)標(biāo)簽內(nèi)，找到 github 相關(guān)的憑據(jù)，此時你可以將已經(jīng)存在的憑據(jù)密碼更新成剛才復(fù)制的 token 信息，或者直接將已經(jīng)存在的 github 憑據(jù)刪除，這樣再推送到 github 時會要求你進(jìn)行登錄，重新登錄時將密碼錄入為你復(fù)制的 token 信息即可

當(dāng)推送成功之后，再次點擊代碼倉庫的 Actions 菜單，則會顯示已經(jīng)執(zhí)行的 workflow 記錄，當(dāng)我們點擊具體的一個 workflow 記錄，則可以顯示出 workflow 中每個步驟的執(zhí)行詳情，你可以根據(jù)執(zhí)行情況自行調(diào)整，至此，也就完成自動化部署的功能

參考

GitHub Actions 入門教程

是時候體驗一下github action的魅力了

npm-ci

Git Extensions is a great tool but the credential management is very weak

到此這篇關(guān)于使用 Github Actions 自動部署 Angular 應(yīng)用到 Github Pages的文章就介紹到這了,更多相關(guān)Github Actions 自動部署 Github Pages內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！