GitHub Actions 实践总结

GitHub Actions 实践总结

GitHub Actions是GitHub推出的一种持续集成和持续部署（CI/CD）工具，可以帮助开发者自动化项目的构建、测试和部署流程。本文将从基本概念、配置文件详解到实际应用案例，全面介绍如何使用GitHub Actions提高开发效率。

GitHub Actions发布有一段时间了，自己用的也挺嗨，过来总结一下。我主要在两个地方用到了，一个是博客，另一个是打包、发布前端项目。整体功能上 Actions 和GitLab CI/CD差不多，同样实现了项目的自动化测试、打包、部署，不过 Actions 利用了 GitHub 开源项目平台的特点，提供了Marketplace，可以直接复用其他作者的 Action。

GitHub Actions提供了Marketplace，方便我们对其他好的Action进行复用，可以说这也是相比Gitlab CI/CD最大的优势了，因为在很多技术栈相同的情况下，CI/CD的流程也是差不多相同的，很多其他厂商也可以为自己的项目提供一个自动化测试、部署的最佳实践，规范了流程也提高了效率。

概念

GitHub Actions里的术语大致有Workflow（工作流）、Job（任务）、Step（步骤），他们大致的关系也是依次递进一对多的形式，比如：一个项目可以有多个Workflow，一个Workflow可以有多个Job，一个Job可以有多个Step。

Workflow

持续集成一次运行的过程，类似Gitlab CI/CD中的Pipeline的概念。GitHub Actions里也需要runner用于执行这些Workflow，可以在项目的Settings里配置自己部署的runner。

Jobs

Jobs用于表示要运行各个任务，也类似Gitlab CI/CD中的Jobs的概念，不同的Job也可以跑在不同的机器上面，他们可以是并行运行的，也可以按一定顺序进行的。

Step

Step定义了Job里要执行的每一个步骤，同时定义了执行的顺序，Step的值是一个列表，即每一个Step也需要多个操作命令才能完成这一件事。

Action

可能有人觉得Workflow和Action是一回事，毕竟这个功能就叫GitHub Actions，我认为还是有点区别的：能封装出来给别人用的叫Action，自己为项目定义的全流程叫Workflow，后面的内容我也会以此为原则进行表达。可以参考官方的描述。

配置文件

一个Workflow的配置文件，一般放在.github/workflows/下面，可以自定义文件名，并以.yml格式为后缀。GitHub只要发现.github/workflows目录里面有.yml文件，就会“编译”该文件，根据文件定义的规则选择什么时候怎么执行。除了上面介绍的概念，还需要一些其他的关键字，才能完成整个Workflow的执行。

name

定义了Workflow的名称。

on

on指定了什么情况下触发执行Workflow。

on:
  push:
    branches:
- main
- 'releases/**'

on.workflow_call

自己制作一个Actions时，通过workflow_call里配置inputs、secrets可以实现参数的动态输入，从而实现可复用的Action。

jobs.id

Job的id是一个字符串，是用于区分不同job的唯一标识符，只能包含字母、数字、-或_。下面例子里my_first_job和my_second_job就是job的id。

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

jobs.runs-on

runners运行的环境，枚举有：

• windows-latest
• ubuntu-latest
• macos-latest

jobs.needs

needs的值为job_id，表示step的依赖顺序。

jobs.if

有一些Step是根据条件判断是否执行的，在if下面，环境变量可以省略${{ }}。

jobs.environment

声明环境的name和url，会在Actions UI中显示。

jobs.steps.id

也可以step定义一个id，并可以通过上下文被使用。

jobs.steps.uses

使用开源的其他项目复用一部分操作。

jobs.steps.with

在uses复用了其他的项目，可能需要with配置一些输入的参数。

jobs.steps.run

run参数指定在runner上执行自己的命令。

环境变量 env

环境变量env可以用来定义一些会多次使用的变量，通过env命令声明，然后通过${{ env.XXX }}使用。

env:
  DAY_OF_WEEK: Monday
jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
- name: "Say Hello Mona it's Monday"
        if: ${{ env.DAY_OF_WEEK == 'Monday' }}
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

GitHub Actions内置了一些默认的环境变量可以直接使用，比如分支名GITHUB_REF_NAME等，更多请参考官方文档。

上下文 context

上下文和环境变量类似，但是也有区别：环境变量只存在于执行任务的机器上；而上下文在workflow的任何时间节点都存在，包括默认环境变量不可用的时候。例如，在将job路由到runner执行之前，需要对gitHub的上下文进行判断。

name: CI
on: push
jobs:
  prod-check:
    if: ${{ github.ref == 'refs/heads/main' }}
    runs-on: ubuntu-latest
    steps:
- run: echo "Deploying to production server on branch $GITHUB_REF"

实战：发布一个Vue应用

写了一个Vue的demo项目，想在代码提交后直接发布到GitHub Pages，我在Marketplace已经找到了满足需求的Action：VuePagesAction，项目主页提供了配置Example，可以直接在自己的项目里创建Workflow。

name: Build Vue
on: [push]
jobs:
  build_vue:
    runs-on: ubuntu-latest
    name: Build Vue
    steps:
- uses: actions/checkout@v2
- id: Build-Vue
      uses: xRealNeon/VuePagesAction@1.0.1
      with:
        username: 'YourGithubName'
        reponame: 'YourRepoName'
        token: ${{ secrets.GITHUB_TOKEN }} # Leave this line unchanged

在提交代码到GitHub后，此条Workflow就会自动运行，并发布到GitHub Pages，可以参考我的项目demo。

HCL？main.workflow？

之前为了能够自动化发布我的博客，也废了不少功夫，我还写了两个Action：publish-hugo-site和push-to-master，不过用的还是以前使用HCL的main.workflow的写法，在新的workflow场景下GitHub已经不支持这种方式了，不能再使用，具体可以看GitHub的声明。

参考

• GitHub Actions官方文档
• GitHub Actions入门教程 - 阮一峰