阿里云服务器ECS    
弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新 [咨询更多]
阿里云存储OSS
简单易用、多重冗余、数据备份高可靠、多层次安全防护安全性更强、低成本 [咨询更多]
阿里云数据库RDS
稳定可靠、可弹性伸缩、更拥有容灾、备份、恢复、监控、迁移等方面的全套解决方案 [咨询更多]
阿里云安全产品
DDoS高防IP、web应用防火墙、安骑士、sll证书、态势感知众多阿里云安全产品热销中 [咨询更多]
阿里云折扣优惠    
云服务器ECS、数据库、负载均衡等产品新购、续费、升级联系客服获取更多专属折扣 [咨询更多]
使用GithubActions自动部署Angular应用到GithubPages
2020-7-20    点击量:
    使用GithubActions自动部署Angular应用到GithubPages
    前言#
    最近在学习Angular,一些基础的语法也学习的差不多了,就在github上新建了一个代码仓库,准备用ng-zorro搭个后台应用的模板,方便自己以后写些小东西时可以直接使用。前端项目,最主要的还是能够实际看到,因此考虑找个地方部署,因为自己的博客是部署到githubpage上的,并且这个项目也只是一个静态网站,所以这里同样选择使用githubpage
    同时,考虑到发布项目时,虽然使用githubpage已经帮我们省略了拷贝文件到服务器上这一步,但是还是需要自己手动的敲命令来完成项目的发布,因为发布的流程很单一,所以这里选择通过githubaction这个自动化工具来实现程序的自动化部署
    StepbyStep#
    2.1、手动部署#
    示例的Angular应用,你可以通过AngularCLI直接生成,如有需要,可以点击此链接进行跳转查看(电梯直达),这里就不演示创建的过程了
    按照正常的前端项目发布流程,当我们需要发布时,需要使用npm命令来完成项目的打包。整个项目中所涉及的npm命令,我们可以通过查阅项目的package.json文件中的scripts节点进行查看

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

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

    当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"
    }
    }

接执行自定义的ngdeploy命令即可
    2.2、自动部署#
    在上面的操作中虽然实现了将程序部署到githubpage,但是还是需要我们手动的通过npm命令来完成部署,接下来就进行改造,通过githubactions来实现自动部署
    githubactions与其它的各种自动化工具相似,允许我们通过指定特定的git事件来触发我们的自动化任务,例如这里我需要在推送代码到服务器的master分支时自动触发程序的发布事件
    你可以在代码仓库的Actionstab页面新增一个workflow,也可以直接在本地代码根路径中新建一个.github/workflows文件夹来存放相关的脚本,因为githubactions的执行脚本采用的是yaml格式,所以这里对于代码格式有着严格的要求,而每一个yaml文件则是一个单独的workflow
每一个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有被勾选上,
在编辑权限时确保workflow有被勾选上
    复制生成的token信息,打开电脑的凭据管理器,在Windows凭据标签内,找到github相关的凭据,此时你可以将已经存在的凭据密码更新成刚才复制的token信息,或者直接将已经存在的github凭据删除,这样再推送到github时会要求你进行登录,重新登录时将密码录入为你复制的token信息即可
重新登录时将密码录入为你复制的token信息即可
    当推送成功之后,再次点击代码仓库的Actions菜单,则会显示已经执行的workflow记录,当我们点击具体的一个workflow记录,则可以显示出workflow中每个步骤的执行详情,你可以根据执行情况自行调整,至此,也就完成自动化部署的功能
完成自动化部署的功能

联系客服免费领取更多阿里云产品新购、续费升级折扣,叠加官网活动折上折更优惠