什么是 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_job和my_second_job。
(5)jobs..needs
needs字段指定当前任务的依赖关系,即运行顺序。
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
上面代码中,job1必须先于job2完成,而job3等待job1和job2的完成才能运行。因此,这个 workflow 的运行顺序依次为:job1、job2、job3。
(6)jobs..runs-on
runs-on字段指定运行所需要的虚拟机环境。它是必填字段。目前可用的虚拟机如下。
ubuntu-latest,ubuntu-18.04或ubuntu-16.04 windows-latest,windows-2019或windows-2016 macOS-latest或macOS-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_name、middle_name 和 last_name)。 这些输入变量将被 hello-world 操作作为 INPUT_FIRST_NAME、INPUT_MIDDLE_NAME 和 INPUT_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/action-ssh@0.1.1
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 目录下配置参数的时候不要加哦。
参考阅读
官方文档阮一峰博客案例
作者:迹_Jason
原文地址:https://segmentfault.com/a/1190000021914414
喜欢 0
文章链接
发表评论