使用GithubActions自动部署Angular应用到GithubPages

网站编辑2020-07-20 13:54:01627

使用GithubActions自动部署Angular应用到GithubPages
前言#
最近在学习Angular，一些基础的语法也学习的差不多了，就在github上新建了一个代码仓库，准备用ng-zorro搭个后台应用的模板，方便自己以后写些小东西时可以直接使用。前端项目，最主要的还是能够实际看到，因此考虑找个地方部署，因为自己的博客是部署到githubpage上的，并且这个项目也只是一个静态网站，所以这里同样选择使用githubpage
同时，考虑到发布项目时，虽然使用githubpage已经帮我们省略了拷贝文件到服务器上这一步，但是还是需要自己手动的敲命令来完成项目的发布，因为发布的流程很单一，所以这里选择通过githubaction这个自动化工具来实现程序的自动化部署
StepbyStep#
2.1、手动部署#
示例的Angular应用，你可以通过AngularCLI直接生成，如有需要，可以点击此链接进行跳转查看（电梯直达），这里就不演示创建的过程了
按照正常的前端项目发布流程，当我们需要发布时，需要使用npm命令来完成项目的打包。整个项目中所涉及的npm命令，我们可以通过查阅项目的package.json文件中的scripts节点进行查看

这里通过AngularCLI创建的项目可以通过ngbuild命令来完成项目的打包发布

当build命令执行完成后，项目根路径下dist文件夹中以项目名称命名的文件夹就是我们需要部署的文件。此时，如果是部署到自己的服务器上，只需要把这个文件夹拷贝到服务器上，通过nginx之类的服务器指向文件所在路径即可
同样的，当我们想要部署到githubpage时，我们也只需要将文件提交到github代码仓库中即可，之后github会自动完成应用的部署工作
因为git默认是会忽略编译生成的dist文件夹的，此时，想要把编译生成的文件推送到远程仓库，你需要修改.gitignore文件，或是通过subtree的形式，将dist文件夹作为一个分支推送到远程服务器

#创建并切换到gh-pages分支
gitcheckout-bgh-pages
#将dist文件夹下的文件添加到gh-pages分支
gitadd-fdist
#提交到本地分支
gitcommit-m'createdgh-pages'
#推送到远程分支
gitsubtreepush--prefixdistorigingh-pages

当然，这样还是显得有些麻烦，对于angular应用来说，我们完全可以使用社区提供的angular-cli-ghpages插件来简化这个操作
首先我们需要通过npm将插件安装到需要部署的程序中

ngaddangular-cli-ghpages

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

ngdeploy--base-href=/ingos-admin/

在之前学习angular中路由时有提到，在angular应用中，框架会将index.html文件中的base标签的href属性值配置为组件、模板、模块文件以及其它一些静态文件的基础路径地址。而当我们将程序部署到githubpage时，实际对应的网站地址是https://<username>.github.io/<repositoryname>，因此，这里如果不指定href的话，程序会在根路径下去寻找站点相关的静态文件，毫无疑问，最终是无法找到的，所以这里我们需要调整href属性值为我们的仓储名称
可以看到，在打包生成的index.html文件中，插件已经帮我们修改了base标签的href地址。以后当我们需要更新网站时，再使用上面的命令即可发布到githubpage上

使用上面的命令即可发布到githubpage上

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

{
"name":"ingos-admin",
"version":"1.0.0",
"scripts":{
"ng":"ng",
"start":"ngserve",
"build":"ngbuild",
"deploy":"ngdeploy--base-href=/ingos-admin/",
"test":"ngtest",
"lint":"nglint",
"e2e":"nge2e"
}
}

2.2、自动部署#
在上面的操作中虽然实现了将程序部署到githubpage，但是还是需要我们手动的通过npm命令来完成部署，接下来就进行改造，通过githubactions来实现自动部署
githubactions与其它的各种自动化工具相似，允许我们通过指定特定的git事件来触发我们的自动化任务，例如这里我需要在推送代码到服务器的master分支时自动触发程序的发布事件
你可以在代码仓库的Actionstab页面新增一个workflow，也可以直接在本地代码根路径中新建一个.github/workflows文件夹来存放相关的脚本，因为githubactions的执行脚本采用的是yaml格式，所以这里对于代码格式有着严格的要求，而每一个yaml文件则是一个单独的workflow

这里我通过直接调整github默认的workflow文件来实现自动化部署功能，整个yaml文件包含了如下的三个部分
name：当前workflow配置的名称
on：任务触发时机，这里是在向github上的master分支提交代码以及提交PR时进行触发
jobs：需要触发的任务信息，一个workflow可以包含多个的job，这里只有一个名为build的job

#ThisisabasicworkflowtohelpyougetstartedwithActions
name:CI
#Controlswhentheactionwillrun.Triggerstheworkflowonpushorpullrequest
#eventsbutonlyforthemasterbranch
on:
push:
branches:[master]
pull_request:
branches:[master]
#Aworkflowrunismadeupofoneormorejobsthatcanrunsequentiallyorinparallel
jobs:
#Thisworkflowcontainsasinglejobcalled"build"
build:
#Thetypeofrunnerthatthejobwillrunon
runs-on:ubuntu-latest
#Stepsrepresentasequenceoftasksthatwillbeexecutedaspartofthejob
steps:
#Checks-outyourrepositoryunder$GITHUB_WORKSPACE,soyourjobcanaccessit
-uses:actions/checkout@v2
#Runsasinglecommandusingtherunnersshell
-name:Runaone-linescript
run:echoHello,world!
#Runsasetofcommandsusingtherunnersshell
-name:Runamulti-linescript
run:|
echoAddotheractionstobuild,
echotest,anddeployyourproject.

一个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在宿主机中执行gitcheckout命令来拉取代码；另一种，则是我们通过run属性来手动编写脚本
对于我们想要的实现的功能，其实只包含了如下的四步：拉取代码=》安装node.js环境=》还原依赖=》部署发布
对于拉取代码以及安装node.js环境，我们可以使用github官方的action来简化我们的脚本，因为我们在每次构建时都需要执行npminstall命令来还原项目所需的各种依赖，因此这里在执行install命令之前，我们可以通过官方的actions/cache@v2来缓存项目依赖，以加快构建的过程
这里在还原依赖时，使用到了npmci而不是npminstall，从命令的名称就可以看出，ci主要是在各种自动化环境构建时使用，通过读取package-lock.json文件中所包含的具体的依赖版本信息来加快还原过程

steps:
#Checks-outyourrepositoryunder$GITHUB_WORKSPACE,soyourjobcanaccessit
-uses:actions/checkout@v2
#Installnodejs
-name:SetupNode.jsenvironment
uses:actions/setup-node@v1
with:
node-version:12.x
#Cachenodemodules
-name:Cachenodemodules
uses:actions/cache@v2
env:
cache-name:cache-node-modules
with:
#npmcachefilesarestoredin`~/.npm`onLinux/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}}-
#Installrequireddependenciestobuildapp
-name:Installdependencies
run:npmci

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

steps:
#Useangular-cli-ghpagestodeployapp
-name:Deploytogithubpages
env:
GITHUB_TOKEN:${{secrets.GITHUB_TOKEN}}
run:npmrundeploy

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

当我们添加了环境变量之后，还需要对我们的实际执行的npm命令脚本进行一个调整
在本地执行发布命令时，本地的git配置中已经包含了相关的账户信息，而当在workflow中执行时因为处于一个匿名的状态，angular-cli-ghpages没办法知道具体的执行人是谁，因此，我们需要在ngdeploy命令中添加上git账户相关的配置参数

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

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

#Thisisabasicworkflowtodeployangularappintogithubpages
name:DeployGithubPages
#Controlswhentheactionwillrun.Triggerstheworkflowonpushorpullrequest
#eventsbutonlyforthemasterbranch
on:
push:
branches:[master]
#Aworkflowrunismadeupofoneormorejobsthatcanrunsequentiallyorinparallel
jobs:
build:
#Thetypeofrunnerthatthejobwillrunon
runs-on:ubuntu-latest
#Stepsrepresentasequenceoftasksthatwillbeexecutedaspartofthejob
steps:
#Checks-outyourrepositoryunder$GITHUB_WORKSPACE,soyourjobcanaccessit
-uses:actions/checkout@v2
#Installnodejs
-name:SetupNode.jsenvironment
uses:actions/setup-node@v1
with:
node-version:12.x
#Cachenodemodules
-name:Cachenodemodules
uses:actions/cache@v2
env:
cache-name:cache-node-modules
with:
#npmcachefilesarestoredin`~/.npm`onLinux/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}}-
#Installrequireddependenciestobuildapp
-name:Installdependencies
run:npmci
#Useangular-cli-ghpagestodeployapp
-name:Deploytogithubpages
env:
GITHUB_TOKEN:${{secrets.GITHUB_TOKEN}}
run:npmrundeploy

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

打开GitHubPersonalAccessTokens页面，点击右侧的Generatenewtoken按钮，选择新建一个token信息，在编辑权限时确保workflow有被勾选上，

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