Github Actions 持续集成服务

什么是 Github Actions

GitHub Actions 是 GitHub 的持续集成服务,于2018年10月推出。是一种可以替换 Travis CI 作为 CI/CD 的解决方案。我也是近期存在一个需求,才开始进行尝试的,毕竟学了用是最好的学习方法。

可能存在一部分同学对持续集成服务(CI/CD)到底能做什么不是特别的有概念,例如:你将代码提交到 Github 仓库,马上将代码打包,发布到应用服务器上,实现快速发布。这个过程就是持续集成服务做得事,期间涉及登录远程服务器、运行测试等等。如果你之前用过 Jenkins 或者 Travis CI,我相信你已经知道,它是做什么了。

GitHub 做了一个官方市场,可以搜索到他人提交的 actions。另外,还有一个 awesome actions 的仓库,也可以找到不少 actions。如何使用别人的 actions 我会在下面说明。

基本概念

GitHub Actions 有一些自己的术语。

(1)workflow (工作流程):持续集成一次运行的过程,就是一个 workflow。

(2)job (任务):一个 workflow 由一个或多个 jobs 构成,含义是一次持续集成的运行,可以完成多个任务。

(3)step(步骤):每个 job 由多个 step 构成,一步步完成。

(4)action (动作):每个 step 可以依次执行一个或多个命令(action)。

编写 Action

GitHub Actions 配置文件存放在代码仓库的.github/workflows目录下,文件后缀为 .yml ,支持创建多个文件,命名随意,一般默认为 main.yml 。GitHub 会根据目录下的 actions 配置,自动触发,无需人为介入,如果运行过程中存在问题,会以邮件的形式通知到你。

下面看一些常用的基础配置项:

(1)name

name 字段是 workflow 的名称。如果省略该字段,默认为当前 workflow 的文件名。

name: GitHub Actions Demo

(2)on

on 字段指定触发 workflow 的条件,通常是某些事件。

on: push

上面代码指定,push 事件触发 workflow。

on 字段也可以是事件的数组。

on: [push, pull_request]

上面代码指定,push 事件或pull_request 事件都可以触发 workflow。

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

(3)on..

指定触发事件时,可以限定分支或标签。

on:
  push:
    branches:    
      - master

上面代码指定,只有master分支发生push事件时,才会触发 workflow。

(4)jobs..name

workflow 文件的主体是jobs字段,表示要执行的一项或多项任务。

jobs字段里面,需要写出每一项任务的job_id,具体名称自定义。job_id里面的name字段是任务的说明。

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

上面代码的jobs字段包含两项任务,job_id分别是my_first_jobmy_second_job

(5)jobs..needs

needs字段指定当前任务的依赖关系,即运行顺序。

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

上面代码中,job1必须先于job2完成,而job3等待job1job2的完成才能运行。因此,这个 workflow 的运行顺序依次为:job1job2job3

(6)jobs..runs-on

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

  • ubuntu-latestubuntu-18.04ubuntu-16.04
  • windows-latestwindows-2019windows-2016
  • macOS-latestmacOS-10.14

下面代码指定虚拟机环境为ubuntu-18.04

runs-on: ubuntu-18.04

(7)jobs..steps

steps字段指定每个 Job 的运行步骤,可以包含一个或多个步骤。每个步骤都可以指定以下三个字段。

  • jobs..steps.name:步骤名称。
  • jobs..steps.run:该步骤运行的命令或者 actions。
  • jobs..steps.env:该步骤所需的环境变量。
  • jobs..steps.uses:该步骤使用的其他的 actions。

下面是一个完整的 workflow 文件的范例。

name: Greeting from Mona
on: push

jobs:
  my-job:
    name: My Job
    runs-on: ubuntu-latest
    steps:
    - name: Print a greeting
      env:
        MY_VAR: Hi there! My name is
        FIRST_NAME: Mona
        MIDDLE_NAME: The
        LAST_NAME: Octocat
      run: |
        echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

上面代码中,steps 字段只包括一个步骤。该步骤先注入四个环境变量,然后执行一条 Bash 命令。

uses

uses 可以引用别人已经创建的 actions,就是上文中说的 actions 市场中的 actions。

引用格式:userName/repoName@verison

with

输入参数的 map 由操作定义。 每个输入参数都是一个键/值对。 输入参数被设置为环境变量。 该变量的前缀为 INPUT_,并转换为大写。

示例

定义 hello_world 操作所定义的三个输入参数(first_namemiddle_namelast_name)。 这些输入变量将被 hello-world 操作作为 INPUT_FIRST_NAMEINPUT_MIDDLE_NAMEINPUT_LAST_NAME 环境变量使用。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/hello_world@master
        with:
          first_name: Mona
          middle_name: The
          last_name: Octocat 

实战演示

我有一个静态博客服务,我希望每当我有新的文章提交到 Github 之后,能自动帮助我发布到我自行购买的服务器上。博客我是通过 Nginx 方式发布的。

main.yml

name: deploy to aliyun
on:
  push:
    branches:
      - master  # 当分支 master 有新纪录提交的时候触发
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # 切换分支
      - name: Checkout
        uses: actions/checkout@master
      # Deploy
      - name: SSH Execute Commands
        uses: JimCronqvist/[email protected]
        with:
            hosts: ${{ secrets.ACCESS_HOST }}
            privateKey: ${{ secrets.ACCESS_TOKEN }}
            command: |
              cd /usr/local/nginx/html/full-stack
              git pull origin master

${{ secrets.ACCESS_HOST }} 是变量的应用方式,该种方式可以避免将一些密码、服务器地址、钥对外暴露,ACCESS_HOST 设置通过当前 Github 项目页面下 Settings -> Secrets 目录下进行配置。

secrets. Settings -> Secrets 目录下配置参数的时候不要加哦。

参考阅读

你可能感兴趣的:(github,github-actions)