GitHub Actions部署静态网页到AWS的S3

GitHub Actions简介

每一个repo可以配置多个workflow，每一个workflow都有对应的.yml文件，存放在repo的.github/workflows路径下。使用git操作时，GitHub识别到该路径下的yml文件就开始自动运行。

GitHub Actions构成

GitHub Actions的一次持续集成或持续部署由workflow、job、step、action构成，四者呈上下级关系。

• workflow：每一次运行过程就是一个workflow
  • job：一个或多个job构成一个workflow，job可以根据项目情况自定义，如build和deploy可以为一个job，也可以代表两个job
    • step： 每一个job由一个或多个step构成，step之间具有运行的先后顺序
      • action： 每个step可以通过一个或多个action来执行，action可以通过userName（或repoName）/actionName来引用别人的action

workflow的yaml文件

每一个repo可以配置多个workflow，每一个workflow都有对应的.yml文件，存放在repo的.github/workflows路径下。使用git操作时，GitHub识别到该路径下的yml文件就开始自动运行。

1. name

        显示在Repo的Actions的Workflows列表中，默认为workflow的文件名，可以通过name配置

name: custom name

2. on

workflow的触发条件，只填写push时调试只有在主干分支push代码才会触发，也可以用数组方式简写多个主干分支的触发条件，或者指定分支和该分支下的git操作。

除了常见的push、pull代码触发操作外，还可以配置scheduled events定时触发、munual events（自定义workflow_dispatch、repository_dispatch）以及其他的webhook events（create创建分支）触发

on: push
# on: [push, pull_request]

# on:
#     push:
#         branches:
#         - main
#     pull_request:
#         branches:
#         - dev

# on:
#   repository_dispatch:
#     types: [opened, deleted]

3. jobs

jobs默认parallel运行，可以通过needs增加运行依赖，从而改为sequential运行。build和deploy为job的id，name会显示在运行日志中，deploy的needs配置了build，表示build job运行后才能执行deploy job。runs-on为必填，指定了运行所需要的虚拟环境。if指定了运行条件。github.ref == 'refs/heads/main'指定了只有当主干分支的push和pull会触发deploy job

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout code
      uses: actions/checkout@v2
    
    - name: Install Node.js
      uses: actions/setup-node@v1
      with:
        node-version: 14.x
    
    - name: Install NPM packages
      run: npm ci
    
    - name: Build project
      run: npm run build
    
    - name: Run tests
      run: npm run test
      
    - name: Upload production-ready build files
      uses: actions/upload-artifact@v2
      with:
        name: production-files
        path: ./build
  
  deploy:
    name: Deploy
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    
    steps:
    - name: Download artifact
      uses: actions/download-artifact@v2
      with:
        name: production-files
        path: ./build
        
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-1

    - name: Deploy static site to S3 bucket
      run: aws s3 sync ./build s3://cow-test-coverage

4. steps

steps指定每个job的运行步骤，步骤可以运行命令、设置任务、repo的某一个action或者public repo和Docker registry发布的action（step并不局限于action，但action都在step中运行）。每个step都在其所在runner中独立运行（runner为job自己的运行环境），但step可以访问以及改变workspace和filesystem。

GitHub默认的第一个step是Set up Job，默认的最后一个step是Complete Step，Set up Job之后的step是运行actions/checkout@v2这一action，进行Checkout code，然后会Install Node14，接着Install NPM packages，这里的命令是npm ci，因此本地的repo需要运行一次npm i，生成package-lock.json，并且push到远端的repo，这样在持续集成时比npm install更快。这一步骤完成后，会进行打包和测试，并且将跑过测试后的打包文件上传到./build路径下，在deploy job允许运行的时候再从这个文件路径下载下来，进行这两个step主要是因为他们处于不同的runner。

最后可以部署到AWS的s3服务或者GitHub的Page上。就可以将前端页面渲染在AWS的静态网页或者GitHub的静态网页上。这一步军需要配置一些access_key，AWS需要配置aws-access-key-id、aws-secret-access-key和aws-region，GitHub Page需要配置github_token。部署静态网页的时候要注意文件路径和前面保持一致，否则拿不到数据。

每个步骤常用的字段有：name（步骤名称）、run（步骤运行的命令）、env（步骤所需的环境变量）、uses（步骤运行需要引用的action）、with（action定义的入参）

参考文献

• GitHub Actions 入门教程：GitHub Actions 入门教程 - 阮一峰的网络日志
• GitHub官方文档：GitHub Actions Documentation - GitHub Docs