GitHub Action一次看个透

这篇具有很好参考价值的文章主要介绍了GitHub Action一次看个透。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

大家好,我是小九九的爸爸,本次给大家带来的内容是自动化部署。聊到这个方向,大家肯定都会想到CI、CD等一系列名词。那这次就来一遍看个透吧。这篇文章肯定会有没讲到的地方,也欢迎大家在评论区里补充。

首先来说一下 部署(Deployment),它其实就是代码发布的一种行为。就拿前端来举例子,如果是开发的工具库的话,那肯定避免不了下面的流程:

  • npm config set registry xxx
  • npm login
  • npm version xxx
  • npm publish
  • npm run build(生成工具库的使用文档以及changelog)
  • 将使用文档推到服务器上或者免费的托管平台。

这一套下来,你说是否繁琐呢,不好定义。这个时候出现了自动部署的概念。相当于你把你固定的操作流程写成一个任务清单,然后自动化部署工具执行这个任务清单就完事了。

所以你看,自动部署(Continuous Deployment,简称CD)干了什么事呢?其实就是帮你执行那些重复的部署动作。当然,如果你觉得手动部署也花费不了自己多长时间,那自动部署对你来说就完全没必要了。

实现自动化部署有哪些方案呢?Jenkins是一个,GitHub Action也是一个解决方案。

那我们本篇文章的主角就出来啦,GitHub Action。

GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台,这个平台主要是依靠“工作流”的概念来完成部署的功能。同时,它也可以将整个运行流程给可视化出来。下图就是我们今天要做出来的成果:

GitHub Action一次看个透,github,持续部署

如何使用GitHub Action?

这个功能是依附在GitHub平台上的,所以要求就是你的项目必须托管在GitHub上。为了方便学习GitHub Action,我们可以随便在自己的账号下建一个项目,建项目的流程在这里就省略了,请自行发挥。

上面我们说过,这个功能是围绕“工作流”来展开。那我们就来说说“工作流”的概念吧。

什么是工作流?

工作流是一个可配置的自动化流程,将运行一个或多个作业。工作流由YAML文件定义。

上面这句话我第一次看的时候,其实内心是懵逼的,后来我知道了,它想表述的是一个工作流,就是一个yaml文件,就是一个可以执行具体命令的容器。yaml文件的位置是有要求的,位于项目根目录下的.github目录下的workflows目录里。我的项目名称叫做play-github-action,所以我的项目结构应该是下面这样的:

/**
    | - play-github-action
        | - .github
            | - workflows
                - 11.yml
                - learn-github-action.yml
*/

工作流有哪些配置?

配置 说明 是否必输
name 表明这次工作流的名称
on 表明工作流里的任务什么时候被执行
jobs 表明工作流里的任务集合
concurrency 表明工作流里的最大任务数量

说了那么多,我们来配置下yml文件,来看看效果:

# learn-github-action.yml配置如下:
name: learn-github-action
on: [push]
# 11.yml配置如下:
name: 11
on: [push]

当我们push代码的时候,这2个工作流就会被执行,此时回到GitHub平台,点击actions页签来看一下具体的情况:

GitHub Action一次看个透,github,持续部署
从上面的工作流程,我们可以暂时得出GitHub Action平台有以下几点规律:

  • 只要你push来代码,就会执行yml文件。这是因为我们使用了on关键字。当然如果你想指定push某个分支时再执行话,这也是可以的。这种需求很常见,比如main分支里有yml文件,你今天基于main分支新切了一个develop分支,那此时develop分支里,自然就会有main分支的yml文件。如果你想指定push main分支时才会运行workflow,那么你可以这么写:
name: CI
on:
  push:
    branches: [ main ]

  • 在这个平台里,一个yml就是一个数据list,点进去我们就会看到具体的任务,以及任务里的步骤。
  • 当我们多次提交后,会发现,其实每个yml文件的执行顺序是不固定的。这是因为工作流之间默认的工作方式是并发。
  • 上面的workflows报错啦,符合预期,因为我们并没有定义jobs。

什么是作业?

我们以单页面应用来举例子,我们部署应用的时候一般会经历以下步骤:

  • 拉取代码
  • 安装依赖
  • 执行打包
  • 将打包后的产物推到远程服务器里

那这个时候,这4个动作就可以被认为是4个作业。当然,你也可以把这4个动作合并为一个作业,你甚至也可以分解为2个作业,这完全取决于用户。

那如何声明job呢?使用jobs关键字。jobs定义里一个集合,你需要将跟本次需求相关的job都放入到这个集合里。还需要声明一点,当一个workflow里拥有多个job时,默认情况下,job的执行顺序是并行的。

作业有哪些配置?

配置 说明 是否必输
jobs.job_id 作业的id
jobs.job_id.runs-on 定义运行job时的计算机类型。其实就相当于指定服务器的运行系统。
jobs.job_id.steps 完成id为job_id的任务,需要执行的步骤集合。
jobs.job_id.steps.run 执行shell命令,相当于node里的child_process。
jobs.job_id.steps.use 用于获取你上传的代码。
jobs.job_id.name 当前作业id的名称。如果你只配置里job_id,那么平台会认为作业的id、name是一样的。
jobs.job_id.needs 定义job之间的关系

又说了那么多,我们再来修改下配置,然后再see one see 效果:

# learn-github-action.yml配置如下:
name: learn-github-action
on: [push]
jobs:
  checkout-bats-version1:                     # job_id
    name: checkout-version1-name              # job_id.name
    runs-on: ubuntu-latest                    # job_id.runs-on
    steps:
      - uses: actions/checkout@v1             # 检出代码
      - uses: actions/setup-node@v3
        with: 
          node-version: '14'
      - run: npm install -g bats               # 执行命令
      - run: bats -v

push一下代码,我们再来看下效果:

GitHub Action一次看个透,github,持续部署

learn-github-action.yml文件执行成功了,但是 11.yml 文件失败了。符合预期,因为我们只改了learn-github-action.yml文件。点进去看一下:

GitHub Action一次看个透,github,持续部署

那我如果再加一个任务呢?

name: learn-github-action
on: [push]
jobs:
  checkout-bats-version1:                #job1
    name: checkout-version1-name
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v3
        with: 
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v
  checkout-bats-version2:               #job2
    name: checkout-version2-name
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v3
        with: 
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

运行一下,效果如下:

GitHub Action一次看个透,github,持续部署
这个效果图告诉我们,当前这2个任务是并行的关系。那如何表示任务之间是继发的呢?needs关键字闪亮登场,修改yml文件如下:

name: learn-github-action
on: [push]
jobs:
  checkout-bats-version1:                #job1
    name: checkout-version1-name
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v3
        with: 
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v
  checkout-bats-version2:                #job2
    name: checkout-version2-name
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v3
        with: 
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v
  checkout-bats-version3:                #job3
    needs: [checkout-bats-version1, checkout-bats-version2]
    name: checkout-bats-version3-name
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v3
        with: 
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

运行以后,我们就得到了文章开头的那个图。这段代码表示,job3的运行之前,必须先运行job1、job2。

可能会用到的其他知识点

上下文

它其实就是一个对象,这个对象里包含里当前workflow的信息、当前workflow下的每个job的信息、当前workflow下的所有变量的信息等等。

那如何访问上下文对象呢?语法如下:

${{ context上下文 }}

它可以在任何地方被使用,比如可以在if表达式里使用。举个例子,上面的步骤中,我们不是使用了on关键字实现了push指定分支才触发workflow嘛,我们也可以使用上下文来实现这个功能:

name: learn-github-action
on: [push],
jobs:
  checkout-bats-version1:                     # job_id
    name: checkout-version1-name              # job_id.name
    if: ${{ github.ref == 'refs/heads/main' }}
    runs-on: ubuntu-latest                    # job_id.runs-on
    steps:
      - uses: actions/checkout@v1             # 检出代码
      - uses: actions/setup-node@v3
        with: 
          node-version: '14'
      - run: npm install -g bats               # 执行命令
      - run: bats -v

只有当if条件通过啦,github action才会将 名为checkout-version1-name的job 发送到运行器ubuntu-latest上,将作业发送到运行器后,执行job下的步骤。在这个步骤里,我们使用了内置的github上下文,还有很多内置的上下文,具体的可以去 上下文 - GitHub 文档看看。

环境变量

在env关键字下设置变量,语法如下:

name: learn-github-action
on: [push],
env:
    DAY_OF_WEEK: Monday

部署

github action也支持将前端工具发布到npm上,具体的操作,相信有前面的铺垫后,阅读起来应该不成问题。

最后

好啦,本期分享到这里就结束啦,希望我的分享对你有帮助,如果你觉得还可以,也可以给我来一个3星好评,我们下期再见啦~~文章来源地址https://www.toymoban.com/news/detail-827444.html

到了这里,关于GitHub Action一次看个透的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • vitepress项目使用github的action自动部署到github-pages中,理论上可以通用所有

    .githubworkflowsdeploy.yml 完整的代码:使用的是 pnpm 进行依赖安装。 这段 YAML 文件定义了一个 GitHub Actions 工作流,用于在推送到 docs 分支时构建和部署 VitePress 项目。 on : 定义触发工作流的事件,这里是在推送到 docs 分支时触发。 jobs : 定义工作流中的任务。 build-and-deploy : 任务

    2024年01月17日
    浏览(49)
  • GitHub Action 通过SSH 自动部署到云服务器上

    准备 正式开始之前,你需要掌握 GitHub Action 的基础语法: workflow (工作流程):持续集成一次运行的过程,就是一个 workflow。 name: 工作流的名称。 on: 指定次工作流的触发器。push 表示只要有人将更改推送到仓库就会触发工作流运行。(点击这里了解如何指定特定分支,路径

    2024年01月19日
    浏览(46)
  • 尝鲜!最新 VitePress 1 版本 + Github action,自动部署个人静态站点 SSG

    今天查看 vue 文档时,刚好看到 vue 官网宣布 VitePress 1 更新了: 然后在路上走着走着,突然想着,也许我可以把我的笔记仓库转换成在线文档(毕竟纯粹的 md 笔记,喜欢的人不多)。 同时,由于我很久之前有过这 vuepress 的使用经验,而且前段时间又复习了一下 github action,

    2024年04月08日
    浏览(55)
  • 【日常记录】自动化部署与持续交付:GitHub Actions CICD

    当我们做项目的时候,如果做完了,要发布,就需要打包,扔到服务器上,如果改了一点东西,还得打包,扔到服务器上,重复的执行 打包= 扔到服务器上 详细记录如何使用github actions自动化部署项目 自动化部署与持续交付:GitHub Actions CICD 自动化部署一般以下方式 Jenkins

    2024年02月02日
    浏览(63)
  • github-webhook+docker实现项目可持续自动化部署

    使用nginx+pm2+github-webhook+docker实现项目自动部署 注:docker也能实现pm2的守护进程功能(持续启动项目),所以使用了docker就不需要使用pm2了 但是需要注意的是使用node启动的webhook服务器不能使用docker,因为在webhook内部的sh脚本执行时需要到服务器的前后端项目文件中去执行,

    2024年04月12日
    浏览(64)
  • 【github】使用github action 拉取国外docker镜像

    k8s部署经常用到国外镜像,如果本地无法拉取可以考虑使用github action环境 github action的ci服务器在国外,不受中国防火墙影响 github action 自带docker命令 运行时直接将你仓库代码拉取下来 你的国内docker仓库,拿到docker login的命令(这个根据不同的云获取,建议不要用dockerhub)

    2024年01月25日
    浏览(36)
  • GitHub Action 使用

    GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台,可用于自动执行生成、测试和部署管道。 您可以创建工作流程来构建和测试存储库的每个拉取请求,或将合并的拉取请求部署到生产环境。GitHub 提供 Linux、Windows 和 macOS 虚拟机来运行工作流程,或者您可以在自己的数据中

    2024年02月07日
    浏览(73)
  • TIPS 关于github action cache

    如果不知道github action 是什么,建议不要继续阅读。 github action cache 官方手册 github action cache 首页 action cache 可以帮助我们缓存一些action生成的数据。一次action的job执行 成功 ,我们可以指定缓存哪个目录或哪些目录的文件。 言外之意,job执行失败,是不会缓存数据的。 缓存

    2024年02月16日
    浏览(25)
  • 白嫖GitHub Action实现开源项目CICD

    在今天这个快速变化的时代,开发者们需要与时俱进,不断提升自己的工作效率。在这篇文章里,将一起探讨如何使用CI/CD和Github Action让你的项目更加高效,快速响应市场变化。 CI(持续集成,Continuous Integration)是一种软件开发实践,它要求开发者频繁地将代码集成到共享的

    2023年04月26日
    浏览(48)
  • 【Github-Action】统计整个社区所有项目的贡献

    项目地址 如果你对github-action感兴趣,还可以看这篇文章, 这篇文章教会你如何开发Github Action,并且让你明白它是什么,怎么用,如何做到的。如何开发一个action 我是一个生成 contributors.png 的 github-action,我和市面上其他的不一样,我专门解决整个 Organization 的 commit 统计,

    2024年01月16日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包