目录

Jenkins配置前端自动打包部署若依项目

Jenkins配置前端自动打包部署(若依项目)

前提说明:三台服务器: gitlab 一台     jenkins一台     项目服务器

一、新建项目

创建一个 Freestyle Project

https://i-blog.csdnimg.cn/blog_migrate/e346aaf36ae7994707fe021b4a1c9d05.png

二、拉取 github 代码

点击 新建 Item 创建一个 Freestyle Project https://i-blog.csdnimg.cn/blog_migrate/4c1b650ef0bc283eb4e34ba5e71e5148.png

在配置页面–>General,勾选[丢弃旧的构建],填写保存的构建天数和构建的最大个数

https://i-blog.csdnimg.cn/blog_migrate/83b58924efc8539a752a76384a5987e1.png

https://i-blog.csdnimg.cn/blog_migrate/48d2510a9ebe967294455b50c34e8c90.png

源码管理 处选择 git ,输入仓库地址,点击添加。 https://i-blog.csdnimg.cn/blog_migrate/6a2250810618d8a46aa084ac6145c1ed.png

三、build 打包

https://i-blog.csdnimg.cn/blog_migrate/ce90e4a39340a38bf3198e3a63b06224.png Execute shell 里写脚本,对前端代码进行打包压缩具体代码如下:



# 安装 npm 依赖并构建项目

npm --registry https://registry.npmmirror.com install

# 构建测试环境

npm run build:stage

脚本解释与写法总结:

1.我看很多博客 这里写很多,对于初学者 ,可能摸不到头脑,我该怎么写,才能自动构建到测试环境。

2.buid steps:构建步骤,也就是构建环境配置、打包进行处理。

首先前端打包问题。

Q:jenkins 从 gitlab 服务拉取的代码在哪里打包呐?

A:拉取的代码在这目录下 /var/lib/jenkins/workspace/ https://i-blog.csdnimg.cn/blog_migrate/e2f0b0c4b8fc4db300ac07b2a194ffb1.png

在 jenkins 控制台查看 https://i-blog.csdnimg.cn/blog_migrate/d02a936ea33833d80216e12c2b26e4b3.png

,代码有了,jenkins 打包,但你得安装 nodejs 吧   安装 npm  安装依赖吧,比如你的写下面这写

 安装依赖
npm install

# 建议不要直接使用 cnpm 安装依赖,会有各种诡异的 bug。可以通过如下操作解决 npm 下载速度慢的问题

npm install --registry=https://registry.npmmirror.com
然后打包,构建测试环境。使用下面命令
# 构建测试环境
npm run build:stage

前端打包完,会生成一个 dist 文件夹 https://i-blog.csdnimg.cn/blog_migrate/156983e6b8aca0b7d298c13740193684.png

好了。这就打包好了。也相当于 buid 好了。

接下来,我的把这个 dist 文件夹发送到另一台测试环境服务器。

四、部署到测试服务器

在真实的开发场景中, Jenkins 几乎不会和前端资源放到一个服务器。大多数情况下 Jenkins 所处的服务器环境就是一个工具用的服务器,放置了一些公司中常用的工具。因此构建到指定的服务器也至关重要。

1、安装发送到远程插件

系统管理 -> 插件管理 搜索 Publish Over SSH 进行安装。 https://i-blog.csdnimg.cn/blog_migrate/9e448332882ad99fe53b2b0584881e7e.png

Send build artifacts over SSH https://i-blog.csdnimg.cn/blog_migrate/33f06456e807a9e3b35c4ca7d30965a1.png

选项解释:

  • Source files : 要上传到目标服务器的文件。它是一个相对路径,相对于 Jenkins 的工作目录 由于上面的 build 打包后  ,在工作目录中生成一个 dist 文件夹,所以这里写相对路径    /dist/
    写法说明
    /dist/*一个*代表 匹配 dist 文件夹所以文件,但是 dist 文件夹下面的 static 文件夹不会部署到测试服务器(不这样写)
    /dist/**2 个* 能把 dist 文件夹下的所有文件夹和文件都能部署到测试服务器(我这样写的)
  • Remove prefix :移除的路径,这里移除 dist 路径
    比如:这里写     dist/    表示:我只部署 dist 文件夹中 static 部分内容,我肯定要把 dist 文件夹去掉,只在测试服务器显示 static 文件,这就用到这个选项了。
  • Remote directory :发送到的服务端路径(这里填目标服务器发送文件夹的目标路径)
    1.这里不填:表示你在系统设置中,也有这个插件,已经设置过了。
    例如:我在系统设置中设置了 /opt/ruoyi        这里就不要设置了。 你如果在设置目标路径,会重复,也就是把 dist 发送到 /opt/ruoyi/opt/ruoyi/dist  子文件家中了,纯属套娃了。
  • Exec command :发送成功后执行的命令(选填)

https://i-blog.csdnimg.cn/blog_migrate/75a4b66c36294b9384a7d306fb9fbb39.png

部署方式:(我就测试 2 种写法)

1.把整个前端 dist 文件夹都部署上传到测试服务器   。 我这样写 :就把整个 dist 源文件夹发送到测试服务器就行,其他不写。 https://i-blog.csdnimg.cn/blog_migrate/33f06456e807a9e3b35c4ca7d30965a1.png

把部分前端 dist 文件夹中 static 文件和其他文件部署上传到测试服务器   。(比较实用)

https://i-blog.csdnimg.cn/blog_migrate/b17de78e9a22252f3abced217cc4699a.png

如图: https://i-blog.csdnimg.cn/blog_migrate/22461c28d09dd35ae6a2f0e5e0d149f7.png

说明:

Source files 写法规则介绍

为了使事情更加灵活,我们添加了一个额外的功能,这使得匹配多个目录级别成为可能。这可用于匹配完整的目录树,或目录树中任何位置的文件。

为此, ** 必须将用作目录的名称。

** 在模式中将用作目录的名称时,它将匹配零个或多个目录。

例如: /test/** 匹配 下的所有文件/目录 /test/ ,例如 /test/x.java 、 或 /test/foo/bar/xyz.html ,但不匹配 /xyz.xml

有一种“简写”——如果模式以 / 或结尾 \ ,则 ** 附加 。

例如, mypackage/test/ 被解释为 mypackage/test/**

https://i-blog.csdnimg.cn/blog_migrate/7db57e8d6e30f648e5c9491c5ae8abd7.png

五、控制台看构建是否成功

https://i-blog.csdnimg.cn/blog_migrate/c81c0168f14f475017547bbc9a7f8e2e.png

https://i-blog.csdnimg.cn/blog_migrate/66e7381cc7fcff790aab2d12d0bf7a57.png