一、概述

1.1Github Action介绍

 什么是Github Action ?

GitHub Actions是GitHub提供的CI/CD（持续集成/持续部署）服务。它允许你在GitHub仓库中自动化、定制和执行你的软件开发工作流。你可以发现、创建和分享用于执行任何你想要的工作的操作，包括CI/CD，并在完全定制的工作流中组合操作。 

它可以帮助你通过自动化的构建（包括编译、发布、自动化测试）来验证你的代码，从而尽快地发现集成错误。github于2019年11月后对该功能全面开放，现在所有的github用户可以直接使用该功能。GitHub 提供 Linux、Windows 和 macOS 虚拟机来运行您的工作流程，或者您可以在自己的数据中心或云基础架构中托管自己的自托管运行器。在使用Github Action之前首先需要了解以下前置知识:

• 持续集成/持续交付的概念。
• Git相关知识。
• Linux或Windows或macOS脚本相关知识。
• Yaml基础语法。

1.2基本概念 

• workflow: 一个 workflow 就是一个完整的工作流过程，每个workflow 包含一组 jobs任务。
• job : jobs任务包含一个或多个job ，每个 job包含一系列的 steps 步骤。
• step : 每个 step 步骤可以执行指令或者使用一个 action 动作。
• action : 每个 action 动作就是一个通用的基本单元。

1.3Github Action 的使用限制

在使用免费版本的Github Action是有如下限制的:

• 作业执行时间 - 工作流中的每个作业最多可以运行 6 小时的执行时间。如果作业达到此限制，该作业将终止且无法完成。

• 工作流运行时间 - 每个工作流运行限制为 35 天。如果工作流运行达到此限制，则工作流运行将被取消。此时间段包括执行持续时间以及等待和批准所花费的时间。

• API 请求 - 您可以在一小时内跨存储库中的所有操作执行多达 1000 个 API 请求。如果超出此限制，其他 API 调用将失败，这可能会导致作业失败。

• 并发作业 - 可以在帐户中运行的并发作业数取决于 GitHub 计划，如下表所示。如果超出，则任何其他作业都将排队。

• 作业矩阵 - 作业矩阵每次工作流运行最多可以生成 256 个作业。此限制适用于 GitHub 托管和自托管的运行程序。

• 工作流运行队列 - 每个存储库的排队时间间隔不超过 500 个工作流运行，间隔为 10 秒。如果工作流运行达到此限制，则工作流运行将终止且无法完成。

 相关Github Action文档

1.4工作流程

持续集成

GitHub Actions 可以用于实现持续集成（Continuous Integration，简称 CI）。持续集成是一种开发实践，开发人员会频繁地（比如每天）将代码集成到主分支。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽早地发现集成错误。 

持续交付

要使用 GitHub Actions 进行持续交付，你需要创建一个名为 .github/workflows 的目录，并在其中添加一个 YAML 文件来定义你的工作流程。

持续部署

总结

二、GitHubAction的使用

持续集成流程

1.开启github共享项目

2.在项目库根路径下的.github/workflows目录中创建一个.yml 文件（或者 .yaml）

name: Java CI with Maven  # 工作流程的名称

on:  # 触发工作流程的事件
  push:  # 当有新的推送到以下分支时
    branches: [ "master" ]  # master分支
  pull_request:  # 当有新的拉取请求到以下分支时
    branches: [ "master" ]  # master分支

jobs:  # 工作流程中的任务
  build:  # 任务的名称

    runs-on: ubuntu-latest  # 任务运行的环境，这里是最新版本的Ubuntu

    steps:  # 任务中的步骤
    - uses: actions/checkout@v3  # 使用actions/checkout@v3来检出仓库代码
    - name: Set up JDK 17  # 步骤的名称，这里是设置JDK 17
      uses: actions/setup-java@v3  # 使用actions/setup-java@v3来设置JDK
      with:  # 步骤的参数
        java-version: '17'  # JDK的版本
        distribution: 'temurin'  # JDK的发行版
        cache: maven  # 缓存Maven依赖
    - name: Build with Maven  # 步骤的名称，这里是使用Maven构建项目
      run: mvn -B package --file pom.xml  # 运行Maven命令来构建项目

    # Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive
    - name: Update dependency graph  # 步骤的名称，这里是更新依赖图
      uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6  # 使用advanced-security/maven-dependency-submission-action来提交依赖图

3.推到开发分支

4../github/workflows/拉回本地，修改后并重新推送

原理概述

name

Workflow的名字，随便可以设置，就是工作流的名字。如果省略该字段，默认为当前 workflow 的文件名。

name: hello-github-actions

on

触发的事件，可以是一个事件数组。
在代码仓库Push时触发:

#push时触发
on: push

可以用数组指定多个条件触发:

#push和merge时触发
on: [push, merge]

还可以对条件进行限制触发:

#当master分支push时触发，可以限定分支或标签。
on:
  push:
    branches:
      - master

完整的事件列表，请查看官方文档。除了代码库事件，GitHub Actions 也支持外部事件触发，或者定时运行。

jobs

job

jobs表示要执行的一项或多项任务。jobs可以包含一个或多个job，一个job就是一个任务，这个任务可以包含多个步骤(steps):

jobs:
  job1:
    ...
  job2:
    ...     

需要注意的是每一个Job都是并发执行的并不是按照申明的先后顺序执行的， 如果多个job 之间存在依赖关系，那么你可能需要使用 needs :

jobs:
  job1:
  
  job2:
    needs: job1
  
  job3:
    needs: [job1, job2]

这里的needs声明了job2 必须等待 job1 成功完成，job3必须等待 job1 和 job2依次成功完成。因此，这个 workflow 的运行顺序依次为：job1、job2、job3。needs字段指定当前任务的依赖关系，即运行顺序。 

job->runs-on

runs-on字段指定运行所需要的虚拟机环境。它是必填字段，目前可用的虚拟机如下:

• ubuntu-latest，ubuntu-18.04或ubuntu-16.04。
• windows-latest，windows-2019或windows-2016。
• macOS-latest或macOS-10.14。
  指定job的运行环境:

jobs:
  job1:
    runs-on: ubuntu-18.04
  job2:
    runs-on: macos-10.15
  job3:
    runs-on: windows-2019    

github 会提供一个配置很不错的服务器做为 runner，Windows 和 Linux 虚拟机的硬件规格：

• 2 核处理器。
• 7 GB 内存。
• 14 GB 固态硬盘空间。

macOS 虚拟机的硬件规格：

• 3 核处理器。
• 14 GB 内存。
• 14 GB 固态硬盘空间。

如果你有网络时延的需求，（比如推送及拉取镜像时产生的网络时延），你也可以自建runner 。

.job->env

使用env可以给该任务或者是步骤配置环境变量:

 env:
   name: "zhangsan"
 run: |
   echo $name

环境变量可以配置在以下地方:

• jobs->job->env
• jobs->job->steps.env

job->steps

steps字段指定每个 Job 的运行步骤，每个job由多个step构成，它会从上至下依次执行。steps可以包含一个或多个步骤，每个 step 步骤可以有:

• name：步骤名称，步骤的名称。
• env：该步骤所需的环境变量。
• id : 每个步骤的唯一标识符
• uses : 使用哪个action，这个表示使用别人预先设置好的Actions，比如因为我代码中要用到python，所以就用了actions/setup-python@v1来设置python环境，不用我自己设置了。
• with: 指定某个action 可能需要输入的参数。
• run: 执行哪些指令，具体运行什么命令行代码。
• continue-on-error : 设置为 true 允许此步骤失败job 仍然通过。
• timeout-minutes : step 的超时时间。

例如:

    steps:  # 任务中的步骤
    - uses: actions/checkout@v3  # 使用actions/checkout@v3来检出仓库代码
    - name: Set up JDK 17  # 步骤的名称，这里是设置JDK 17
      uses: actions/setup-java@v3  # 使用actions/setup-java@v3来设置JDK
      with:  # 步骤的参数
        java-version: '17'  # JDK的版本
        distribution: 'temurin'  # JDK的发行版
        cache: maven  # 缓存Maven依赖
    - name: Build with Maven  # 步骤的名称，这里是使用Maven构建项目
      run: mvn -B package --file pom.xml  # 运行Maven命令来构建项目

Action

Github Actions 是GitHub的持续集成服务。持续集成由很多操作组成，比如登录远程服务器，发布内容到第三方服务等等，这些相同的操作完全可以提取出来制作成脚本供所有人使用。GitHub允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用该脚本，这个脚本就是一个Action。如果你需要某种功能的Action可以从GitHub社区共享的action官方市场查找，也可以自己编程Action开源出来供大家使用。既然 actions 是代码仓库，当然就有版本的概念，用户可以引用某个具体版本的 action。 下面都是合法的 action 引用:

actions/setup-node@74bc508 # 指向一个 commit
actions/setup-node@v1.0    # 指向一个标签
actions/setup-node@master  # 指向一个分支

GitHub Actions 中使用密文

在持续集成的过程中，我们可能会使用到自己的敏感数据，这些数据不应该被开源并泄露。那么如何才能安全的使用这些敏感数据呢?GithubActions提供了Secrets变量来实现这一效果。我们可以在 github repo 上依次点击 Settings -> Secrets-> Actions->New repository secret创建一个敏感数据例如:OSS_KEY_ID，OSS_KEY_SECRET， 然后我们就可以在GithubAction脚本中使用这一变量了:

-  name:  setup  aliyun  oss
    uses:  manyuanrong/setup-ossutil@master
    with:
        endpoint:  oss-cn-beijing.aliyuncs.com
        access-key-id:  ${{  secrets.OSS_KEY_ID  }}
        access-key-secret:  ${{  secrets.OSS_KEY_SECRET  }}

这里的secret就是一种context，描述 CI/CD 一个workflow 中的上下文信息，使用${{ expression }}语法表示。更多context信息可以参考官方文档

问题解决

报403Resource not accessible by integration

参考解决方案

快速解决 Resource not accessible by integration

报404"The Dependency graph is disabled for this repository. Please enable it before submitting snapshots.",

这个错误信息表示你正在尝试提交依赖关系快照，但是这个仓库的依赖关系图已经被禁用了。你需要先启用它，然后再提交快照。

你可以按照以下步骤来启用仓库的依赖关系图：

1. 打开你的 GitHub 仓库。
2. 点击仓库的 "Settings"（设置）选项卡。
3. 在左侧的导航栏中，点击 "Security & analysis"（安全与分析）。
4. 在 "Dependency graph"（依赖关系图）部分，点击 "Enable"（启用）。

完成以上步骤后，你应该就可以提交依赖关系快照了。如果问题仍然存在，你可能需要联系 GitHub 的支持团队以获取更多的帮助。

持续交付流程

 1.找到华为云docker登录指令

2。隐私数据处理

3.设置docker

      name: docker push
      run: |
        ${{ secrets.HUAWEI_DOCKERLOGIN }}
        docker build . -t ${{ secrets.HUAWEI_DOCKERREPOSITORY }}
        docker push ${{ secrets.HUAWEI_DOCKERREPOSITORY }}

 4.推送

持续部署流程

deploy:  # 定义一个名为 "deploy" 的工作
  needs: [build]  # 这个工作需要在 "build" 工作完成后才能开始
  runs-on: ubuntu-latest  # 这个工作将在最新版本的 Ubuntu 虚拟环境中运行
  steps:  # 定义这个工作的步骤
    - name: deploy  # 定义一个名为 "deploy" 的步骤
      uses: appleboy/ssh-action@master  # 使用 appleboy/ssh-action 这个 GitHub Action
      with:  # 为这个 Action 提供参数
        host: ${{ secrets.HUAWEI_HOST }}  # SSH 主机地址
        username: ${{ secrets.HUAWEI_USERNAME }}  # SSH 用户名
        password: ${{ secrets.HUAWEI_PWD }}  # SSH 密码
        script: |  # 要在 SSH 会话中执行的脚本
          ${{ secrets.HUAWEI_DOCKERLOGIN }}  # 登录到 Docker
          docker stop $(docker ps --filter ancestor=${{ secrets.HUAWEI_DOCKERREPOSITORY }} -q)  # 停止所有使用指定 Docker 镜像的容器
          docker rm -v $(docker ps --filter ancestor=${{ secrets.HUAWEI_DOCKERREPOSITORY }} -q)  # 删除这些容器
          docker rmi -f $(docker images ${{ secrets.HUAWEI_DOCKERREPOSITORY }} -q)  # 删除指定的 Docker 镜像
          docker pull ${{ secrets.HUAWEI_DOCKERREPOSITORY }}  # 从 Docker 仓库拉取最新的镜像
          docker run -d -p 3080:8080 ${{ secrets.HUAWEI_DOCKERREPOSITORY }}  # 运行新的 Docker 容器，将容器的 8080 端口映射到主机的 3080 端口