使用 Github Actions 自动部署 Angular 应用到 Github Pages的方法

前言

最近在学习 Angular,一些基础的语法也学习的差不多了,就在 github 上新建了一个代码仓库,准备用 ng-zorro 搭个后台应用的模板,方便自己以后写些小东西时可以直接使用。前端项目,最主要的还是能够实际看到,因此考虑找个地方部署,因为自己的博客是部署到 github page 上的,并且这个项目也只是一个静态网站,所以这里同样选择使用 github page

同时,考虑到发布项目时,虽然使用 github page 已经帮我们省略了拷贝文件到服务器上这一步,但是还是需要自己手动的敲命令来完成项目的发布,因为发布的流程很单一,所以这里选择通过 github action 这个自动化工具来实现程序的自动化部署

代码仓库地址:ingos-admin

预览地址:https://yuiter.com/ingos-admin

Step by Step

2.1、手动部署

示例的 Angular 应用,你可以通过 Angular CLI 直接生成,如有需要,可以点击此链接进行跳转查看(电梯直达),这里就不演示创建的过程了

按照正常的前端项目发布流程,当我们需要发布时,需要使用 npm 命令来完成项目的打包。整个项目中所涉及的 npm 命令,我们可以通过查阅项目的 package.json 文件中的 scripts 节点进行查看

这里通过 Angular CLI 创建的项目可以通过 ng build 命令来完成项目的打包发布

当 build 命令执行完成后,项目根路径下 dist 文件夹中以项目名称命名的文件夹就是我们需要部署的文件。此时,如果是部署到自己的服务器上,只需要把这个文件夹拷贝到服务器上,通过 nginx 之类的服务器指向文件所在路径即可

同样的,当我们想要部署到 github page 时,我们也只需要将文件提交到 github 代码仓库中即可,之后 github 会自动完成应用的部署工作

因为 git 默认是会忽略编译生成的 dist 文件夹的,此时,想要把编译生成的文件推送到远程仓库,你需要修改 .gitignore 文件,或是通过 subtree 的形式,将 dist 文件夹作为一个分支推送到远程服务器

# 创建并切换到 gh-pages 分支
git checkout -b gh-pages
# 将 dist 文件夹下的文件添加到 gh-pages 分支
git add -f dist
# 提交到本地分支
git commit -m 'created gh-pages'
# 推送到远程分支
git subtree push --prefix dist origin gh-pages

当然,这样还是显得有些麻烦,对于 angular 应用来说,我们完全可以使用社区提供的 angular-cli-ghpages 插件来简化这个操作

首先我们需要通过 npm 将插件安装到需要部署的程序中

ng add angular-cli-ghpages

安装完成之后,我们就可以通过 ng deploy 命令来完成部署,插件会自动把打包生成的文件发布到 github 上,并创建一个 gh-pages 分支作为 github page 显示的站点

ng deploy --base-href=/ingos-admin/

在之前学习 angular 中路由时有提到,在 angular 应用中,框架会将 index.html 文件中的 base 标签的 href 属性值配置为组件、模板、模块文件以及其它一些静态文件的基础路径地址。而当我们将程序部署到 github page 时,实际对应的网站地址是 https://<username>.github.io/<repositoryname>,因此,这里如果不指定 href 的话,程序会在根路径下去寻找站点相关的静态文件,毫无疑问,最终是无法找到的,所以这里我们需要调整 href 属性值 为我们的仓储名称

可以看到,在打包生成的 index.html 文件中,插件已经帮我们修改了 base 标签的 href 地址。以后当我们需要更新网站时,再使用上面的命令即可发布到 github page 上

因为每次执行 ng deploy 命令时都需要在命令中添加 base-href 参数,所以这里我们可以在 package.json 文件中添加一个 script,这样当后面我们需要发布时,直接执行自定义的 ng deploy 命令即可

{
 "name": "ingos-admin",
 "version": "1.0.0",
 "scripts": {
 "ng": "ng",
 "start": "ng serve",
 "build": "ng build",
 "deploy": "ng deploy --base-href=/ingos-admin/",
 "test": "ng test",
 "lint": "ng lint",
 "e2e": "ng e2e"
 }
}

2.2、自动部署

在上面的操作中虽然实现了将程序部署到 github page,但是还是需要我们手动的通过 npm 命令来完成部署,接下来就进行改造,通过 github actions 来实现自动部署

github actions 与其它的各种自动化工具相似,允许我们通过指定特定的 git 事件来触发我们的自动化任务,例如这里我需要在推送代码到服务器的 master 分支时自动触发程序的发布事件

你可以在代码仓库的 Actions tab 页面新增一个 workflow,也可以直接在本地代码根路径中新建一个 .github/workflows 文件夹来存放相关的脚本,因为 github actions 的执行脚本采用的是 yaml 格式,所以这里对于代码格式有着严格的要求,而每一个 yaml 文件则是一个单独的 workflow

这里我通过直接调整 github 默认的 workflow 文件来实现自动化部署功能,整个 yaml 文件包含了如下的三个部分

  • name:当前 workflow 配置的名称
  • on:任务触发时机,这里是在向 github 上的 master 分支提交代码以及提交 PR 时进行触发
  • jobs:需要触发的任务信息,一个 workflow 可以包含多个的 job,这里只有一个名为 build 的 job
# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
 push:
 branches: [master]
 pull_request:
 branches: [master]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
 # This workflow contains a single job called "build"
 build:
 # The type of runner that the job will run on
 runs-on: ubuntu-latest

 # Steps represent a sequence of tasks that will be executed as part of the job
 steps:
 # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
 - uses: actions/checkout@v2

 # Runs a single command using the runners shell
 - name: Run a one-line script
  run: echo Hello, world!

 # Runs a set of commands using the runners shell
 - name: Run a multi-line script
  run: |
  echo Add other actions to build,
  echo test, and deploy your project.

一个 workflow 文件中最重要的就是包含的 jobs,它表明了当前 workflow 所能实现的功能,一个 job 任务主要包含了如下的属性

  • runs-on:当前 job 需要运行在的系统环境
  • steps:实现一个 job 需要执行的各个步骤
  • env:当前 job 执行时需要的各种环境变量
  • needs:当我们定义多个 job 时,默认是并行执行的,但是存在 job2 需要等 job1 执行完成后才可以执行的情况,这时,我们就可以在 needs 属性中指定 job2 依赖于 job1,从而确保整个 workflow 的正确执行

在 steps 节点中,定义了当前 job 需要执行的各个步骤,step 分为两种,一种是我们使用 users 属性来直接引用别人已经发布的 action,例如这里通过引用 github 官方的 actions/checkout@v2 在宿主机中执行 git checkout 命令来拉取代码;另一种,则是我们通过 run 属性来手动编写脚本

对于我们想要的实现的功能,其实只包含了如下的四步:拉取代码 =》安装 node.js 环境 =》还原依赖 =》部署发布

对于拉取代码以及安装 node.js 环境,我们可以使用 github 官方的 action 来简化我们的脚本,因为我们在每次构建时都需要执行 npm install 命令来还原项目所需的各种依赖,因此这里在执行 install 命令之前,我们可以通过官方的 actions/cache@v2 来缓存项目依赖,以加快构建的过程

这里在还原依赖时,使用到了 npm ci 而不是 npm install,从命令的名称就可以看出,ci 主要是在各种自动化环境构建时使用,通过读取 package-lock.json 文件中所包含的具体的依赖版本信息来加快还原过程

steps:
 # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
 - uses: actions/checkout@v2

 # Install node js
 - name: Setup Node.js environment
 uses: actions/setup-node@v1
 with:
  node-version: 12.x

 # Cache node modules
 - name: Cache node modules
 uses: actions/cache@v2
 env:
  cache-name: cache-node-modules
 with:
  # npm cache files are stored in `~/.npm` on Linux/macOS
  path: ~/.npm
  key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
  restore-keys: |
  ${{ runner.os }}-build-${{ env.cache-name }}-
  ${{ runner.os }}-build-
  ${{ runner.os }}-

 # Install required dependencies to build app
 - name: Install dependencies
 run: npm ci

当还原完成之后,就可以执行 package.json 文件中的 deploy 命令了,这里需要注意,因为在 action 中执行的命令更多的都是只读权限,所以为了能够有足够的权限执行发布操作,我们需要在执行时在环境变量中附加上 GITHUB_TOKEN 变量

steps:
 # Use angular-cli-ghpages to deploy app
 - name: Deploy to github pages
 env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 run: npm run deploy

secrets.GITHUB_TOKEN 因为是 github 默认创建的,因此我们可以在 workflow 中直接使用,而对于一些另外需要授权的服务,直接将密码写在 yaml 文件中会不安全,这时你就可以在代码仓库的 settings tab 下通过设置 secrets 密钥信息,然后就可以通过变量的方式在 workflow 中直接使用

当我们添加了环境变量之后,还需要对我们的实际执行的 npm 命令脚本进行一个调整

在本地执行发布命令时,本地的 git 配置中已经包含了相关的账户信息,而当在 workflow 中执行时因为处于一个匿名的状态,angular-cli-ghpages 没办法知道具体的执行人是谁,因此,我们需要在 ng deploy 命令中添加上 git 账户相关的配置参数

{
 "name": "ingos-admin",
 "version": "1.0.0",
 "scripts": {
 "deploy": "ng deploy --no-silent --base-href=/ingos-admin/ --name='账户名' --email='密码'",
 }
}

至此,完整的 workflow 脚本如下,当我们将本地代码推送到 github 仓库时,就会自动完成程序的发布部署

# This is a basic workflow to deploy angular app into github pages
name: Deploy Github Pages

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
 push:
 branches: [master]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
 build:
 # The type of runner that the job will run on
 runs-on: ubuntu-latest

 # Steps represent a sequence of tasks that will be executed as part of the job
 steps:
  # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
  - uses: actions/checkout@v2

  # Install node js
  - name: Setup Node.js environment
  uses: actions/setup-node@v1
  with:
   node-version: 12.x

  # Cache node modules
  - name: Cache node modules
  uses: actions/cache@v2
  env:
   cache-name: cache-node-modules
  with:
   # npm cache files are stored in `~/.npm` on Linux/macOS
   path: ~/.npm
   key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
   restore-keys: |
   ${{ runner.os }}-build-${{ env.cache-name }}-
   ${{ runner.os }}-build-
   ${{ runner.os }}-

  # Install required dependencies to build app
  - name: Install dependencies
  run: npm ci

  # Use angular-cli-ghpages to deploy app
  - name: Deploy to github pages
  env:
   GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: npm run deploy

这里需要需要注意,因为代码中包含了 workflow 文件,可能在推送到 github 时遇到如下的错误,此时需要我们对 access token 进行重新的设置

打开 GitHub Personal Access Tokens 页面,点击右侧的 Generate new token 按钮,选择新建一个 token 信息,在编辑权限时确保 workflow 有被勾选上,

复制生成的 token 信息,打开电脑的凭据管理器,在 Windows 凭据标签内,找到 github 相关的凭据,此时你可以将已经存在的凭据密码更新成刚才复制的 token 信息,或者直接将已经存在的 github 凭据删除,这样再推送到 github 时会要求你进行登录,重新登录时将密码录入为你复制的 token 信息即可

当推送成功之后,再次点击代码仓库的 Actions 菜单,则会显示已经执行的 workflow 记录,当我们点击具体的一个 workflow 记录,则可以显示出 workflow 中每个步骤的执行详情,你可以根据执行情况自行调整,至此,也就完成自动化部署的功能

参考

GitHub Actions 入门教程

是时候体验一下github action的魅力了

npm-ci

Git Extensions is a great tool but the credential management is very weak

到此这篇关于使用 Github Actions 自动部署 Angular 应用到 Github Pages的文章就介绍到这了,更多相关Github Actions 自动部署 Github Pages内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • vue cli 3.x 项目部署到 github pages的方法

    github pages 是 github 免费为用户提供的服务,写博客,或者部署一些纯静态项目. 最近将 vue cli 3.x 初始化项目部署到 github pages,踩了一些坑,记录如下. https://github.com/nusr/resume-vue 1. vue-router 不要开启 history 模式 路径中的 # 比较丑,就开启了 vue-router 的 history 模式,去掉了 #.平时做项目也是默认开启 history 模式.折腾了半天发现,我这是部署到 g

  • 在GitHub Pages上使用Pelican搭建博客的教程

    Pelican 介绍 首先看看 Pelican 的一些主要特性: Python实现,开放源码 输出静态页面,方便托管 支持主题,采用Jajin2模板引擎 支持代码语法高亮 支持reStructuredText.Markdown.AsciiDoc格式 支持Disqus评论 支持Atom和RSS输出 这些特性都是大爱,完全满足我对博客系统的基本需求,再配合免费无限制的GitHub Pages,一切近乎完美了. 安装 Pelican 开始前请自行安装Python环境,支持2.7.X和3.3+,为方便,

  • vue项目打包上传github并制作预览链接(pages)

    当Vue项目完成后,在根目录下打开命令行,输入命令: npm run build 实际上此命令就是执行build.js文件,将项目打包成静态资源. 此命令完成后,项目根目录下会多出一个dist文件夹,dist文件里面有: static文件下包括项目打包后的css.js.img.fonts(字体图标). 项目资源无法加载 点击index.html,浏览器显示该页面是空白的.打开控制台看到index.html文件中没有加载任何css.js文件. 解决方法: 打开项目根目录config下的index.

  • vue项目打包后上传至GitHub并实现github-pages的预览

    vue项目打包后上传至GitHub,并实现github-pages的预览 1. 打包vue 项目 vue项目: 命令行输入打包命令npm run build,生成了dist文件夹: 打包完成. 打包常见问题1--项目资源无法加载 打开刚刚打包好的dist文件夹,浏览器打开index.html 发现该页面是空白的,打开控制台发现 这里看到index.html文件中没有加载任何css.js文件. 解决方法--修改config文件 打开项目根目录config下的index.js文件,进行如下修改: 即

  • 使用 Github Actions 自动部署 Angular 应用到 Github Pages的方法

    前言 最近在学习 Angular,一些基础的语法也学习的差不多了,就在 github 上新建了一个代码仓库,准备用 ng-zorro 搭个后台应用的模板,方便自己以后写些小东西时可以直接使用.前端项目,最主要的还是能够实际看到,因此考虑找个地方部署,因为自己的博客是部署到 github page 上的,并且这个项目也只是一个静态网站,所以这里同样选择使用 github page 同时,考虑到发布项目时,虽然使用 github page 已经帮我们省略了拷贝文件到服务器上这一步,但是还是需要自己手

  • maven自动部署到远程tomcat服务器的方法

    使用maven的自动部署功能可以很方便的将maven工程自动部署到远程tomcat服务器,节省了大量时间. 本文章适用于tomcat的7.x ,8.x, 9.x版本. 下面是自动部的步骤 1,首先,配置tomcat的manager 编辑远程tomcat服务器下的conf/tomcat-users.xml,在末尾增加(其实只要拉到文件末尾,去掉注释改一下就可以了) <role rolename="manager-gui"/> <role rolename="m

  • M2实现Nodejs项目自动部署的方法步骤

    PM2实现Nodejs项目自动部署 首先简单说下思路:本地git仓库与远程仓库关联(github.码云等平台),然后pm2按照指定配置登录服务器,拉取远程仓库的代码更新,再执行一些指定的命令(如打包等). 创建本地项目并关联到远程仓库 本地新建名为web的项目,进入项目并创建一个简单的Nodejs文件app.js, mkdir web && cd web vi app.js 文件内容编辑如下,完成后保存退出:wq!. // app.s const http = require('http'

  • PM2自动部署代码步骤流程总结

    公司的项目需要自动部署到服务器上,在网上查询后,发现PM2自带的发布程序可以自动部署并运行. 0x01 环境条件 本地环境:window10的WSL ubuntu16.04 服务器环境:ubuntu18.04 使用PM2进行部署,可以先查看官方的文档 这里需要在本地和服务器环境上同时安装好 PM2 .git ,本地PM2可以通过git向github.gitee等仓库提交代码,同时通知服务器的PM2拉取最新的代码,并在拉取成功后运行代码. 0x02 设置本地环境与服务器环境gitee仓库ssh 本

  • CentOS7 上利用 jenkins 实现自动部署

    前端项目打包部署,以前都是手工运行打包命令,打包结束后压缩,然后上传到服务器上解压部署.这种重复性的工作,确实有点让人烦,而且效率也不高. 本文基于 vue 的前端项目. GitHub 的代码仓库,简述在 CentOS7 上利用 jenkins 实现自动部署. 一.安装插件 NodeJS Jenkins -> Manage Jenkins -> Manage Plugins -> Avaliable 搜索 NodeJS,勾选 NodeJS,点击 Install without resta

  • 超详细动手搭建一个VuePress 站点及开启PWA与自动部署的方法

    五一之前就想写一篇关于Vuepress的文章,结果朋友结婚就不了了之了. 记得最后一定要看注意事项! Vuepress介绍 官网:https://vuepress.vuejs.org/ 类似hexo一个极简的静态网站生成器,用来写技术文档不能在爽.当然搭建成博客也不成问题. Vuepress特点 响应式,也可以自定义主题与hexo类似 内置markdown(还增加了一些扩展),并且可以在其使用Vue组件 Google Analytics 集成 PWA 自动生成Service Worker 快速上

  • Springboot服务Docker化自动部署的实现方法

    还在手动将springboot项目打包,然后上传服务器,手动执行启动命令将项目启动吗?你out了!通过Docker配置DockerMaven插件,快速部署,一键将springboot服务器部署到服务器,一键启动,告别传统部署方式,实现自动化运维的第一步,心动吗?快来一起看看~ 微服务部署方式 (1)手动部署:首先基于源码打包生成jar包(或war包),将jar包(或war包)上传至虚拟机并拷贝至JDK容器. (2)通过Maven插件自动部署. 对于数量众多的微服务,手动部署无疑是非常麻烦的做法,

  • 如何利用python脚本自动部署k8s

    目录 一.准备 二.编辑脚本 1.k8s.sh 2.k8s_install.py 三.配置ssh免密 四.下载python3和git 五.执行脚本 六.成功 七.总结 一.准备 通过之前在Ubuntu18.04上手动部署过k8s之后,尝试用python脚本进行自动化部署 这次用的是三台centos7的虚拟机,一台作为master执行脚本,两台作为node节点 三台机器都配置好静态IP,可以参考之前的在centos 7中安装配置k8s集群的步骤详解 二.编辑脚本 1.k8s.sh 放在/root下

  • Rainbond自动部署初始化Schema的数据库步骤教程

    目录 为什么使用Rainbond? Schema初始化在传统模式中一般有两种方案: 目录结构 Dockerfile文件 为什么使用Rainbond? 我们使用容器的方式部署数据库组件,特别是企业有大量的项目开发业务的,部署的开发.测试数据库组件较多时.经常会遇到以下问题: 业务需要使用数据库,但部署完数据库后,需要在数据库中执行创建schema的操作或者一些初始化数据的创建. 开发测试多套部署环境,需要多次重复1的步骤. 项目比较多,时间久了项目需要的数据库Schema不清楚. 项目交付时数据库

随机推荐