GitHubActions

用过Gitlab的同学基本上都了解过Gitlab持续集成与持续部署，GitlabCICD是通过自管理的一些Runner按照声明式的的配置清单实现持续集成的自动化任务，利用GithubActions可以自动化管理、构建、部署托管在Github上的代码，当然你可以用它自动化管理和部署你的博客，无需人为干预，也可以利用Actions帮你拉取一些国内拉不到的镜像等，功能有了，至于怎么使用就看个人了，前面我写了几篇关于GitlabCICD的实践文章以及在Kubernetes上如何使用GitlabCICD,大家有兴趣的可以前来审校：

??从GitLabCECI/CD方法论中探索实践??持续构建与部署值GITLAB-RUNNER??GitlabRunner的CI与CD??GitlabCICD与Kubernetes实践·部署GitLab??GitlabCI与Kubernetes实践·部署GitLab-Runner??GitLabCICD与Kubernetes实践·部署FlaskWeb服务

在使用GithubActions的时候，虽然原理和使用方式，但是依旧存在不同的概念关键词，下面简单的介绍一下：

Runner

与GtilabCICD类似，GitlabActions也是在一个运行有GithubActionsrunnerapplication的runner服务器上执行实现定义好的workflow.同样如果你需要不同的操作系统或者硬件配置需求，你也可以自托管Github的runner,这些可以在GitlabAction的文档中找到

所以github中的一些列指定都是在Runner中完成的，runner就是githubaction的执行环境。

Workflows

workflows是github中声明配置的一个自动化过程，与gitlab中的.gitlab-ci.yml一样，有一个或者多个job组成，通过事件驱动构建流程

Jobs

jobs是一系待需要执行的指令的集合，由多个steps组成，可以理解要实现某个目标需要操作的指令集，与gitlab中的stage类似

steps

step是githubactions中执行的任务的单元，是job中运行命令的独立任务单元，github社区中有不少别人贡献出来的action,这些都是完成一类任务的指令集合体，所以你可以在steps中直接引用这些action,也可以自己去写命令，同样的，job中的每个step都运行相同的Runner上执行指令，所以他们之间的数据是可以共享的

events

githubaction是一个事件驱动型的自动化工具，因此在定义workflow的时候，可以灵活的通过on指定事件的类型（如pull,pull_request,tags,branches等）去完成相对应的任务

运行个Demo??创建一个空的github代码仓库在代码仓库里面创建.github/workflows目录创建一个superlinter.yml文件

name:Super-Linter#定义workflows的名称#Runthisworkfloweverytimeanew